假设我们在开发阶段都是基于正式公布版本号来做依赖管理,那么遇到这个问题。就须要升级组件的版本号号,可这样就明显不符合要求和实际情况了。可是,假设是基于快照版本号,那么问题就自热而然的攻克了,而maven已经为我们准备好了这一切。

      maven中的仓库分为两种,snapshot快照仓库和release公布仓库。

snapshot快照仓库用于保存开发过程中的不稳定版本号,release正式仓库则是用来保存稳定的发行版本号。定义一个组件/模块为快照版本号,仅仅须要在pom文件里在该模块的版本号号后加上-SNAPSHOT就可以(注意这里必须是大写),例如以下:




  1. <groupId>cc.mzone </groupId>
  2. <artifactId>m1 </artifactId>
  3. <version>0.1-SNAPSHOT </version>
  4. <packaging>jar </packaging>



      maven2会依据模块的版本号号(pom文件里的version)中是否带有-SNAPSHOT来推断是快照版本号还是正式版本号。假设是快照版本号,那么在mvn deploy时会自己主动公布到快照版本号库中,而使用快照版本号的模块,在不更改版本号号的情况下。直接编译打包时,maven会自己主动从镜像server上下载最新的快照版本号。

假设是正式公布版本号,那么在mvn deploy时会自己主动公布到正式版本号库中。而使用正式版本号的模块。在不更改版本号号的情况下,编译打包时假设本地已经存在该版本号的模块则不会主动去镜像server下载。

      所以,我们在开发阶段,公共图书馆的版本号可以设置为快照版本。是依赖组件被引用的快照版本开发。快照版本更新的公共图书馆后。我们并不需要改变pom文件版本号提示下载新的版本号,直接mvn编译相关的操作、包装命令可以重新下载最新的快照库,从而促进我们的发展。




转载于:

 在使用maven过程。我们经常会在不稳定的状态有很多公共图书馆在发展阶段。需要改变在任何时间和公布,你可能有一天一次发布。经验bug时间,甚至一天公布N次要。我们知道,。maven依赖管理是基于管理的版本号,对于发布状态artifact,假设相同的版本号,即使是我们内部的镜子server上的组件比本地新,maven也不会主动下载的。

假设我们在开发阶段都是基于正式公布版本号来做依赖管理,那么遇到这个问题。就须要升级组件的版本号号,可这样就明显不符合要求和实际情况了。可是,假设是基于快照版本号,那么问题就自热而然的攻克了,而maven已经为我们准备好了这一切。

      maven中的仓库分为两种,snapshot快照仓库和release公布仓库。

snapshot快照仓库用于保存开发过程中的不稳定版本号,release正式仓库则是用来保存稳定的发行版本号。定义一个组件/模块为快照版本号,仅仅须要在pom文件里在该模块的版本号号后加上-SNAPSHOT就可以(注意这里必须是大写),例如以下:




  1. <groupId>cc.mzone </groupId>
  2. <artifactId>m1 </artifactId>
  3. <version>0.1-SNAPSHOT </version>
  4. <packaging>jar </packaging>



      maven2会依据模块的版本号号(pom文件里的version)中是否带有-SNAPSHOT来推断是快照版本号还是正式版本号。假设是快照版本号,那么在mvn deploy时会自己主动公布到快照版本号库中,而使用快照版本号的模块,在不更改版本号号的情况下。直接编译打包时,maven会自己主动从镜像server上下载最新的快照版本号。

假设是正式公布版本号,那么在mvn deploy时会自己主动公布到正式版本号库中。而使用正式版本号的模块。在不更改版本号号的情况下,编译打包时假设本地已经存在该版本号的模块则不会主动去镜像server下载。

      所以,我们在开发阶段,公共图书馆的版本号可以设置为快照版本。是依赖组件被引用的快照版本开发。快照版本更新的公共图书馆后。我们并不需要改变pom文件版本号提示下载新的版本号,直接mvn编译相关的操作、包装命令可以重新下载最新的快照库,从而促进我们的发展。