Maven版本号中隐藏的惊天大秘密

一、背景

​ 现在主流的Java系的互联网公司里，绝大多数公司都使用Maven作为依赖管理工具，一般我们对于依赖的版本号，常见两种类型：一种以“-RELEASE”结尾，另一种以“-SNAPSHOT”结尾。你别看这一个小小差别，在这里面可是隐藏着巨大的秘密：我们在团队协作开发的时候，如果依赖版本号的命名不是很规范的话，往往你会发现一种现象，那就是别人更新了一个依赖，已经提交到了私服上，但是你本地死活拉不下来，最后没有办法，你选择了直接删除本地仓库中的该版本的依赖，然后就完美解决了。但你有没有想一想为什么会出现这种情况？有没有更高效的解决办法？那么本文我们就聊这个。

二、原理以及解决办法

​ 在企业的私服中，会存在snapshot快照仓库和release发布仓库，snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。

​ maven会根据模块的版本号(pom文件中的version)中是否带有“-SNAPSHOT”(注意这里必须是全部大写)来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到私服的快照版本库中;如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中。

​ 如果在一个项目中，我们依赖了模块A的快照版，还依赖了模块B的正式版本，那么在不更改依赖模块版本号的情况下，我们在进行直接编译打包该项目时：即使本地仓库中已经存在对应版本的依赖模块A，maven还是会自动从镜像服务器上下载最新的依赖模块A的快照版本。而依赖正式版本的模块B，如果本地仓库已经存在该版本的模块B, maven则不会主动去镜像服务器上下载。这也是为什么我们会在本地仓库中快照版本的依赖的目录下会看到带有时间戳的jar包，比如下面：

我们知道了这些以后，该怎么解决这个问题呢？

1.暴利解决(不优雅，所以不推荐)

直接在本地maven的配置文件中的私服配置添加如下红框内的配置

2.在打包的时候加上“-U”参数,强制拉取所有依赖的最新代码

mvn clean install -U

3.语义化版本

首先，我们在团队协作时，要定义好开发中的依赖一定不要忘记升级版本号，然后开发的过程中还要保持版本号以“-SNAPSHOT”结尾。来把该依赖作为快照版本进行开发，这样每次别人更新完上传到私服以后，你本地打包时会自动拉取最新代码，从而方便我们的开发和维护。

三、总结

​ 通过本文，我们就明白了为什么快照版本的依赖，maven编译打包的时候无论本地是否存在，都会去私服拉取最新的，而正式版本的依赖，如果本地仓库已经存在，maven不会去私服拉取最新的原因，所以我们要基于快照版本进行开发，但是上线的时候一定记得变成正式版，否则如果本地正在进行开发另一个功能，提交到私服的代码有可能会被误上线。至此我们完美的解决了我们文章开头抛出的问题，并且不是暴利解决。我遇见问题，就喜欢打破砂锅弄到底，用最优雅的方式解决最复杂的问题。关于Maven，我想说的是：入门很简单，但精通有难度！