maven中的snapshot来源与注意事项

maven的依赖管理是基于版本管理的,在maven2之后,把版本管理细化snapshot 快照仓库和release发布仓库。release版本,对于发布状态的artifact(就是被依赖的jar包),如果版本号相同,即使我们内部的镜像服务器上的组件比本地新,maven也不会主动下载的。这里也为snapshot 的出现打下了伏笔。
【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执行相关编译、打包命令即可重新下载最新的快照库了,从而保证了开发进度和质量。

    推荐阅读