maven的依赖管理是基于版本管理的，在maven2之后，把版本管理细化snapshot 快照仓库和release发布仓库。release版本，对于发布状态的artifact（就是被依赖的jar包），如果版本号相同，即使我们内部的镜像服务器上的组件比本地新，maven也不会主动下载的。这里也为snapshot 的出现打下了伏笔。


        快照版本，很多人不是特别理解为什么要有这个事物的出现，它的出现对于编程有什么帮助吗？没有snapshot出现之前，我们开发过程依赖别人开发某个包，通常maven会集中管理这些依赖包，它会要求别人打包成jar放到镜像服务器上，自己本地的pom.xml文件设置了依赖后，maven编译时，会自动从镜像服务器上下载依赖。但如果镜像服务器上有相同版本的依赖时，maven就不会下载，这是上段文字的白话版本，那么举个例子说明一下。


       比如，你的工程要依赖的core版本是 1.0.0 版本，结果这个版本还正处于对方（叫小菜吧）的开发过程中，他利用maven命令mvn install打包成jar，并部署到服务器上，根据pom设定的版本，你顺利下载了依赖包。但小菜后续开发过程，发现了一个致命bug，那么他再操作一次，那么，即使服务器的更新是你需要的，你只能干着急，只能跟小菜吼一声，“你的版本，老子无法更新依赖包，再给我发一个新的版本上去。”小菜一听，好吧，那我把版本升到 1.0.1 版本，你通过update dependencies 下载了这个新版本的jar包。这样的情况，会循环地出现，那么你和小菜有点恼火了，maven就是老鼠钻到风箱里，两头受气，maven想能不能开发一个功能，使双方默认可以上传并打包下载到最新的开发版本，而不用修改版本号，否则开发完成之后，服务器上是一堆的release版本。有了这个思路，maven增加了划时代的功能，snapshot ，这样依赖版本为 1.0.0-SNAPSHOT （注意必须为全大写），当服务器上有更新时，会自动下载到本地，省去了不少、和小菜的沟通时间，也减小了不少由于版本问题带来的编译错误。


      任何东西的使用，需要遵循其规则，snapshot虽然好用，如果使用不当，反而易造成困惑问题。首先，开发一个依赖jar包时，注意snapshot版本号的不同，需要一个统一的地方记录各自的版本，在开发周期很长的情况下，版本号release的顺序并非按版本号顺序发布，重要的是，大家的开发版本号不能重复。如果你也在开发这个core.jar，你依赖于本地，而服务器上别人有也相同版本号的core.jar定期放在服务器上，这样，本地的jar经常会被来自服务器版本覆盖而导致错误。

        总结一下，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而保证了开发进度和质量。

注：maven会自动从仓库中检查模块A的快照版本的最新版本，当发现有更新时便进行下载。默认情况下，maven每天检查一次更新(由仓库配置的updatePolicy控制)，用户也可以使用命令-U参数强制让maven检查更新，如maven clean install -U。
元素updatePlocy说明：用来配置maven从远程仓库检查更新的频率，默认的值为daily,表示每天检查一次。(updatePlocy可以改为internal:1，为每分钟检测一次，但是我测试时未生效，可能跟IDE有关系，未解决这个问题)

除了持续集成服务器外，任何其他人都不应该发布SNAPSHOT版本到Maven仓库，因为只有持续集成服务器的环境是可信任的，你能在本地成功执行mvn clean install并不代表持续集成服务器上该命令能成功，由于每个人的本地环境各有差异，因此集成的成功与否应当以持续集成服务器为准，而只有集成成功后，SNAPSHOT才可以被部署到私有仓库供他人使用。

鉴于上述的原因分析，我认为在基于Maven的持续集成环境中，再怎么强调私有Maven仓库的重要性都是不为过的。

正确的集成命令

在持续集成服务器上使用怎样的 mvn 命令集成项目，这个问题乍一看答案很显然，不就是 mvn clean install 么？事实上比较好的集成命令会稍微复杂些，下面是一些总结：
不要忘了clean： clean能够保证上一次构建的输出不会影响到本次构建。

使用deploy而不是install： 构建的SNAPSHOT输出应当被自动部署到私有Maven仓库供他人使用，这一点在前面已经详细论述。
使用-U参数： 该参数能强制让Maven检查所有SNAPSHOT依赖更新，确保集成基于最新的状态，如果没有该参数，Maven默认以天为单位检查更新，而持续集成的频率应该比这高很多。
使用-e参数：如果构建出现异常，该参数能让Maven打印完整的stack trace，以方便分析错误原因。
使用-Dmaven.repo.local参数：如果持续集成服务器有很多任务，每个任务都会使用本地仓库，下载依赖至本地仓库，为了避免这种多线程使用本地仓库可能会引起的冲突，可以使用-Dmaven.repo.local=/home/juven/ci/foo-repo/这样的参数为每个任务分配本地仓库。
使用-B参数：该参数表示让Maven使用批处理模式构建项目，能够避免一些需要人工参与交互而造成的挂起状态。

综上，持续集成服务器上的集成命令应该为 mvn clean deploy -B -e -U -Dmaven.repo.local=xxx 。此外，定期清理持续集成服务器的本地Maven仓库也是个很好的习惯，这样可以避免浪费磁盘资源，几乎所有的持续集成服务器软件都支持本地的脚本任务，你可以写一行简单的shell或bat脚本，然后配置以天为单位自动清理仓库。需要注意的是，这么做的前提是你有私有Maven仓库，否则每次都从Internet下载所有依赖会是一场噩梦。

--------------------------------------------------------------------------

在每次把快照版本改成发布版本时，都需要把snapshot版本改为release，这样会也会是一个麻烦的事情，所以我们需要使用另外一个部署分发插件assembly来解决这个问题。