maven3实战之仓库(快照版本)
----------
在Maven的世界中,任何一个项目或者构件都必须有自己的版本。版本的值可能是1.0.0,1.3-alpha-4,2.0,2.1-SNAPSHOT或者2.1-20091214.221414-13。其中,1.0、1.3-alpha-4和2.0是稳定的发布版本,而2.1-SNAPSHOT和2.1-20091214.221414-13是不稳定的快照版本。
Maven为什么要区分发布版本和快照版本呢?简单的1.0.0、1.2、2.1等不就够了吗?为什么还要2.1-SNAPSHOT,甚至是长长的2.1-20091214.221414-13?试想一下这样的情况,小张在开发模块A的2.1版本,该版本还未正式发布,与模块A一同开发的还有模块B,它由小张的同事季MM开发,B的功能依赖于A。在开发的过程中,小张需要经常将自己最新的构建输出,交给季MM,供她开发和集成调试,问题是,这个工作如何进行呢?
如果不停更新版本2.1.1、2.1.2、2.1.3....呢?首先,小张和季MM两人都需要频繁地更改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版本最新的文件。这时,季MM配置对于模块A的2.1-SNAPSHOT版本的依赖,当她构件模块B的时候,Maven会自动从仓库中检查模块A的2.1-SNAPSHOT的最新构件,当发现有更新时便进行下载。默认情况下,Maven每天检查一次更新(由仓库配置的updatePolicy控制),用户也可以使用命令行-U参数强制让Maven检查更新,如:mvn clean install-U。
基于快照版本机制,小张在构建成功之后才能将构件部署至仓库,而季MM可以完全不用考虑模块A的构建,并且她能确保随时得到模块A的最新可用的快照构件,而这一切都不需要额外的手工操作。
分享到:
相关推荐
Maven3实战
Maven3实战笔记(全) 从安装配置,到仓库依赖,到集成测试,到插件管理,到构建web 作者风趣幽默的介绍了maven3的使用 强烈推荐
课程目录: Maven3_01_maven概览 Maven3_02_maven安装的注意事项 Maven3_03_在eclipse中建立简单的项目 Maven3_04_maven的依赖特性 Maven3_05_maven的聚合和继承 Maven3_06_复习maven的基本...Maven3实战笔记 Maven配置
Maven3实战笔记 Maven3实战笔记 Maven3实战笔记 Maven3实战笔记
现在可能出现的情况是开发 data-service 的团队正在进行快节奏的bug修复或者项目改进,并且他们几乎每隔一天就要发布库到远程仓库。 现在如果 data-service 团队每隔一天上传一个新版本,那么将会出现下面的问题...
Maven3实战笔记(整合)
Maven3实战笔记——03Maven仓库。
Maven3实战笔记08——Maven反应堆。
Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清 Maven实战 高清
Maven实战Maven实战Maven的安装、配置及使用入门
Maven3实战笔记05——仓库依赖解析与插件解析。
Maven实战(基于Maven3).pdf(340页)
Maven3实战笔记10——使用Maven进行测试。
Maven3实战笔记04——Maven的生命周期和插件。
Maven3实战笔记07——继承的介绍。
Maven3实战笔记06——聚合的介绍。
Maven3实战笔记
Maven3实战笔记,介绍maven构建项目的步骤以及相关内容
《Maven应用实战》源码 杨式文 孙会军 编著 配套源码