Maven SNAOPSHOT 版本能一直更新,而 RELEASE 版本同一个版本号的包只能上传一次
Maven 为什么要区分发布版本和快照版本
试想一下这样的情况,小张在开发模块 A 的 2.1 版本,该版本还未正式发布,与模块 A 一同开发的还有模块B,它由小张的小李开发,B 的功能依赖于 A。在开发的过程中,小张需要经常将自己最新的构建输出,交给小李,供他开发和集成调试,问题是,这个工作如何进行呢?
如果不停更新版本 2.1.1、2.1.2、2.1.3…. 首先,小张和小李两人都需要频繁地更改 POM,如果有更多的模块依赖于模块
A,就会涉及更多的 POM 更改;其次,大量的版本其实仅仅包含了微小的差异,这样也会造成为版本号的滥用
Maven 的快照版本机制就是为了解决上述问题。在该例中,小张只需要将模块 A 的版本设定为2.1-SNAPSHOT,然后发布到私服中,在发布的过程中,Maven 会自动为构件打上时间戳。比如:2.1-20091214.221414-13 就表示 2009 年 12 月 14 日 22 点 14 分 14 秒的第 13 次快照。有了该时间戳,Maven 就能随时找到仓库中该构件 2.1-SNAPSHOT 版本最新的文件。这时,小李配置对于模块 A 的 2.1-SNAPSHOT
版本的依赖,当她构件模块 B 的时候,Maven 会自动从仓库中检查模块 A 的 2.1-SNAPSHOT 的最新构件,当发现有更新时便进行下载。默认情况下,Maven 每天检查一次更新(由仓库配置的 updatePolicy 控制),用户也可以使用命令行 -U 参数强制让 Maven 检查更新,如:mvn clean install-U
基于快照版本机制,小张在构建成功之后才能将构件部署至仓库,而小李可以完全不用考虑模块 A 的构建,并且他能确保随时得到模块 A 的最新可用的快照构件,而这一切都不需要额外的手工操作
快照版本的不稳定性
当项目经过完善的测试后需要发布时,就应该将快照版本改为发布版本。例如,将 2.1-SNAPSHOT 更改为 2.1,表示该版本已经稳定,且只对应了唯一的构件。相比之下,2.1-SNAPSHOT 往往对应了大量带有不同时间戳的构件,这也决定了其不稳定性
快照版本只应该在组织内部的项目或模块间依赖使用,因为这时,组织对于这些快照版本的依赖具有完全的理解及控制权。项目不应该依赖于任何组织外部的快照版本依赖,由于快照版本的不稳定性,这样的依赖会造成潜在危险。也就是说,即使项目构建今天是成功的,由于外部的快照版本依赖实际对应的构件随时可能变化,项目的构建就可能由于这些外部的不受控制的因素而失败