springboot整合之版本号统一管理

特别说明：本次项目整合基于idea进行的，如果使用Eclipse可能操作会略有不同，不过总的来说不影响。

springboot整合之如何选择版本及项目搭建

**springboot整合之版本号统一管理 **

springboot整合mybatis-plus+durid数据库连接池

springboot整合swagger

springboot整合mybatis代码快速生成

springboot整合之统一结果返回

springboot整合之统一异常处理

springboot整合之Validated参数校验

springboot整合之logback日志配置

springboot整合pagehelper分页

springboot整合本地缓存

springboot整合redis + redisson

springboot整合elasticsearch

springboot整合rabbitMq

springboot整合canal实现缓存一致性

springboot整合springSecurity(前后端不分离版本)

相信小伙伴们对于版本号的管理都很熟悉了,那我们在springboot中常见的版本管理有几种方式呢?

一、properties文件统一管理

这种方式也是我们项目中常用的方式，首先这样以来我们能对项目中的ja包版本号进行统一的管理，以后修改版本号都会比较方便。而且这样会减少很多不必要的问题。所以强烈推荐这种管理方式。至于会减少什么问题我们稍后会详细说一说。

​

二、坐标中引入版本号

最常见的就是坐标引入也很简单，如下，直接在pom文件中粘贴就好了。比如下面这个，我们就是引入了swagger-bootstrap-ui的1.9.6版本。

        <!--swagger.ui-->
        <dependency>
            <groupId>com.github.xiaoymin</groupId>
            <artifactId>swagger-bootstrap-ui</artifactId>
            <version>1.9.6</version>
        </dependency>

那么为什么不推荐这种方式来管理jar包版本号呢？ 那就是这种管理方式可能会导致jar包引入不是我们想要的。想要搞明白这个问题我觉得有必要先了解一下spring-boot-starter-parent是如何管理jar包的。

三、spring-boot-starter-parent是如何管理jar包的

就拿下面的mysql驱动来说.

​

在当前项目下我们并没有设置mysql链接驱动的版本号,但是springboot却帮我们自动引入了8.0.25.那么他是怎么做到的呢?

首先就是spring-boot-starter-parent继承了spring-boot-dependencies。spring-boot-dependencies对一些常用的jar包进行了统一的版本号管理。如果有疑问的可以ctrl然后点击一下spring-boot-starter-parent.然后看到下面这个pom文件,其实这个就是spring-boot-starter-parent的pom文件.在这个文件中可以很清晰的看到spring-boot-starter-parent继承了spring-boot-dependencies。

​

然后我们接着按住ctrl,点击spring-boot-dependencies,进入到spring-boot-dependencies的pom文件看一下.可以看到许多常见的jar包版本号springboot都已经帮我们维护好了.而且这些版本号跟当前版本都是兼容的.这样对于我们开发者来说相当的方便,而且不用自己去处理jar包和springboot版本不兼容问题.

​

然后我们在文件中查找MySQL的版本号：​

可以看到当前的mysql版本号就是8.0.25。这就是为啥我们在springboot中不用写版本号但是spring boot却能帮我们自动导入相应版本号jar包的原因。

四、spring-boot-dependencies带来的问题

熟话说事情都有两面性，对于spring boot通过spring-boot-dependencies来进行常用jar包版本号管理也是如此。比如我们现在项目使用的是7.10.2版本的ElasticSearch,但是按照spring boot官方给的说明，我们现在用的是spring boot 2.3.X对应的是7.6.2版本。

相信很多小伙伴在开发中也遇到过这种问题。面对这种问题我们有两种选择，第一种是替换spring boot的版本。这种情况下我们的elastic search肯定是不会有问题的，但是能确保其他jar包不出问题吗？或者项目能够正常运行吗？更可怕的是能正常运行部分功能不正常？所以我们只能是替换spring boot帮我们配置好的版本号。

这也就是为啥我们说不推荐第二种jar包版本管理的原因，因为第二种方式没办法覆盖，但是第一种properties版本号管理可以覆盖。

这样说可能不是很清楚，接下来我们动手实验一下就清晰了。首先我们按照第二种方式引入elasticsearch的依赖。

可以看到版本中不但有7.10.2的依赖，竟然还有我们没有引入的7.6.2的依赖，这也就是很多小伙伴开发中”明明是按照别人的博客CV过来的为啥别人的正常到了我这里就不能用了呢“的原因所在。

然后我们来按照第一种方式来配置一下：

可以看到现在我们的依赖中7.6.2的版本就消失了。

所以强烈建议大家使用第一种jar包管理方式。不要使用第二种。避免不必要的麻烦。因为在spring boot中默认当前项目的properties会比spring-boot-dependencies中的properties优先级要高，所以能够覆盖原来的默认版本号。这样以来就能够减少很多不必要的麻烦。小伙伴们你们学到了吗！！！，如果文章对你有所帮助的话，可以点赞关注~