如何理解正常版本和Snapshot版本
开发中maven真是太常用了,但有时候不明白什么时候用release版本,什么时候用snapshot版本,记住了也老忘
1.认识maven依赖
<dependency>
<groupId>com.test.atomatom98</groupId>
<artifactId>xxxxx-api</artifactId>
<version>1.2.8</version>
</dependency>
随便找一个maven依赖,发现每个dependency都是由几个内容组成的:
- groupId
- artifactId
- version
也就是说这三个内容确定一个依赖,也就是一个jar包或者war包
2.maven仓库中的snapshot和正常版本的区别
在Nexus仓库中,一个仓库一般分为public(Release)仓和SNAPSHOT仓,前者存放正式版本,后者存放快照版本。如果在项目配置文件中(无论是build.gradle还是pom.xml)指定的版本号带有’-SNAPSHOT’后缀,比如版本号为’Junit-4.10-SNAPSHOT’,那么打出的包就是一个快照版本。
- 假设你依赖一个库的正式版本,构建的时候构建工具会先在本次仓库中查找是否已经有了这个依赖库,如果没有的话才会去远程仓库中去拉取。所以假设你发布了Junit-4.10.jar到了远程仓库,有一个项目依赖了这个库,它第一次构建的时候会把该库从远程仓库中下载到本地仓库缓存,以后再次构建都不会去访问远程仓库了。
- 所以如果你修改了代码,向远程仓库中发布了新的软件包,但仍然叫Junit-4.10.jar,那么依赖这个库的项目就无法得到最新更新。你只有在重新发布的时候升级版本,比如叫做Junit-4.11.jar,然后通知依赖该库的项目组也修改依赖版本为Junit-4.11,这样才能使用到你最新添加的功能。
在协同开发中,这样就非常麻烦,因为如果用正式版本,jar包有改动就需要构建,然后下载到本地缓存,然后使用,但是用SNAPSHOT版本就很方便,每次maven导入依赖时,会优先去远程仓库中查看是否有最新的xxxxxx-1.0-SNAPSHOT.jar,如果有则下载下来使用。即使本地仓库中已经有了xxxxxx-1.0-SNAPSHOT.jar,它也会尝试去远程仓库中查看同名的jar是否是最新的。
总结
所以一般在开发模式下,我们可以频繁的发布SNAPSHOT版本,以便让其它项目能实时的使用到最新的功能做联调;当版本趋于稳定时,再发布一个正式版本,供正式使用。当然在做正式发布时,也要确保当前项目的依赖项中不包含对任何SNAPSHOT版本的依赖,保证正式版本的稳定性。