假设我们在开发阶段都是基于正式公布版本号来做依赖管理，那么遇到这个问题。就须要升级组件的版本号号，可这样就明显不符合要求和实际情况了。可是，假设是基于快照版本号，那么问题就自热而然的攻克了，而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编译相关的操作、包装命令可以重新下载最新的快照库，从而促进我们的发展。