php彩票网站建设教程,网站推广名片,常德经开区网站官网,池州网站建设价格在使用maven过程中#xff0c;我们在开发阶段经常性的会有很多公共库处于不稳定状态#xff0c;随时需要修改并发布#xff0c;可能一天就要发布一次#xff0c;遇到bug时#xff0c;甚至一天要发布N次。我们知道#xff0c;maven的依赖管理是基于版本管理的#xff0c;…在使用maven过程中我们在开发阶段经常性的会有很多公共库处于不稳定状态随时需要修改并发布可能一天就要发布一次遇到bug时甚至一天要发布N次。我们知道maven的依赖管理是基于版本管理的对于发布状态的artifact如果版本号相同即使我们内部的镜像服务器上的组件比本地新maven也不会主动下载的。如果我们在开发阶段都是基于正式发布版本来做依赖管理那么遇到这个问题就需要升级组件的版本号可这样就明显不符合要求和实际情况了。但是如果是基于快照版本那么问题就自热而然的解决了而maven已经为我们准备好了这一切。maven中的仓库分为两种snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)如下cc.mzonem10.1-SNAPSHOTjarmaven2会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本那么在mvn deploy时会自动发布到快照版本库中会覆盖老的快照版本而在使用快照版本的模块在不更改版本号的情况下直接编译打包时maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本那么在mvn deploy时会自动发布到正式版本库中而使用正式版本的模块在不更改版本号的情况下编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。所以我们在开发阶段可以将公用库的版本设置为快照版本而被依赖组件则引用快照版本进行开发在公用库的快照版本更新后我们也不需要修改pom文件提示版本号来下载新的版本直接mvn执行相关编译、打包命令即可重新下载最新的快照库了从而也方便了我们进行开发。目前在JAVA的世界中maven已经成为事实上的构建标准很多开源库的管理构建也是基于maven的maven本身的学习曲线比较陡峭遵循“约定优于配置”的理念maven存在很多约定。本次我先描述下关于版本的定义的选择SNAPSHOT or RELEASE版本之争在maven的约定中依赖的版本分为两类——SNAPSHOT和RELEASE。SNAPSHOT依赖泛指以-SNAPSHOT为结尾的版本号例如1.0.1-SNAPSHOT。除此之外所有非-SNAPSHOT结尾的版本号则都被认定为RELEASE版本即正式版虽然会有beta、rc之类说法但是这些只是软件工程角度的测试版对于maven而言这些都是RELEASE版本。既然Maven提供了这两类版本号那么他们之前的优劣势是什么分别在什么场景下使用解读SNAPSHOT同一个SNAPSHOT版本的依赖可以多次发布(deploy)到仓库中也就是说同一个SNAPSHOT版本的依赖可以在仓库中存在多份每一份都是代码在某一个特定时间的快照这也是SNAPSHOT的含义。如上图很好地表达了SNAPSHOT的细节也阐述了一个SNAPSHOT很重要观点——SNAPSHOT不是一个特定的版本而是一系列的版本的集合其中HEAD总是指向最新的快照对外界可见的一般也是最新版这种给人的假象是新的覆盖了老的从而使得使用SNAPSHOT依赖的客户端总是通过重新构建(有时候需要-U强制更新)就可以拿到最新的代码。例如A--B-1.3.8-SNAPSHOT(理解为A依赖了B的1.3.8-SNAPSHOT版本)那么B-1.3.8-SNAPSHOT更新之后重新deploy到仓库之后A只需要重新构建就可以拿到最新的代码并不需要改变依赖B的版本。由此可见这样达到了变更传达的透明性这对于开发过程中的团队协作的帮助不言而喻。SNAPSHOT之殇SNAPSHOT版本的依赖因为存在变更传达的透明性的优势而被赏识甚至被“溺爱”有很多团队索性直接使用SNAPSHOT到生产环境中这样对于变更直接生效很方便。但是作为技术人员的我们其实应该很严谨地看待变更传达的透明性变更就意味着风险透明性更是把风险彻底隐藏了起来生产环境中存在这样的现象更是心惊胆战。例如A--B.1.0.3-SNAPSHOTB对一个A使用的功能实现进行了调整直接发布到仓库A重新构建或许就会失败更糟糕的是构建成功运行时异常。这个时候A甚至完全没有代码变更就突然失败了会带来更多的困惑。这也是maven经常遭人诟病的一个因素对于同一份代码构建结果却不具备确定性让很多人沮丧。当然这个不完全是因为依赖的问题也有maven插件的问题maven之前的版本寻找插件策略的方式也存在不确定性maven在版本2的时候会去寻找最新的插件版本(如果没配置的话)来执行构建经常会找到SNAPSHOT版本的插件所以依赖了一个不稳定的插件来执行构建不确定性就大大增加。不过maven在3版本就改变了这个策略会寻找最新稳定版的插件来执行构建使得构建具备了确定性稳定性也好多了。说明maven本身也在SNAPSHOT的问题上狠狠摔了一跤。归根到底这些问题的根源就是SNAPSHOT是变化的是不稳定的而应用(软件)依赖于变化并且不稳定的SNAPSHOT的依赖会导致自身也在变化和不稳定中这是稳定性的一个大忌依赖不稳定的服务或者依赖上述的maven2的问题就是一个典型反例。RELEASE简介RELEASE版本和SNAPSHOT是相对的非SANPSHOT版本即RELEASE版本RELEASE版本是一个稳定的版本号看清楚咯是一个不是一系列可以认为RELEASE版本是不可变化的一旦发布即永远不会变化。虽然RELEASE版本是稳定不变的但是仓库还是有策略让这个原则变得可配置有的仓库会配置成redeploy覆盖这样RELEASE版本就变成SNAPSHOT了伪装成RELEASE的SNAPSHOT会让问题更费解和棘手我一般称这类人为“挖坑专家”。记住RELEASE一旦发布就不可改变。如何选择那么什么时候使用SNAPSHOT什么时候使用RELEASE?这个可以从他们各自的特性上来看SNAPSHOT版本的库是一直在变化的或者说随时都会变化的这样虽然可以获取到最新的特性但是也存在不稳定因素依赖一个不稳定的模块或者库会让模块自身也变得不稳定尤其是自身对被依赖模块的变化超出掌控的情况。即使可以掌控被依赖模块的变化也会带来不稳定的因素因为每次变更都有引入bug的可能性。如果这么说那么我们是不是要摒弃SANPSHOT了呢答案肯定是否定的。想象下什么情况下模块会一直变化或者变化比较剧烈开发新特性的时候所以对于团队之间协同开发的时候模块之间出现依赖变化会非常剧烈如模块A依赖模块B模块A必然需要最方便地获取模块B的特性在开发期间方便性比稳定性更重要。可以反证下假设模块B使用RELEASE版本1.0.0模块A依赖1.0.0现在模块A出现了bug需要修复下那么A就要提供一个版本号1.0.1这样所有依赖A模块都需要更新版本号因为开发期间这种事情是如此多所以会带来巨变。反观SNAPSHOT方案如果模块B的版本是1.0.0-SNAPSHOT模块A完全不需要修改版本号即可获取模块B的新特性。当开发进入预发布阶段为了生产环境的稳定性依赖应该是RELEASE版本因为此时SNAPSHOT版本的模块自动获取新特性的特点恰恰会造成生产环境的不稳定性生产环境上稳定性重于一切。魔幻之手现在已经很明确了在开发期间活跃模块的版本号使用SNAPSHOT在生产期间依赖RELEASE版本模块。貌似我们找到了银弹不过这个只是理想状态即所有的模块的版本都在自己的掌控或者间接掌控下只有这样你才能影响对应模块的版本号。往往是理想很丰满现实却很骨感如果你依赖的一个模块只有SNAPSHOT版本并且该模块也很活跃最无助的是模块的维护人不理会你的请求那么是否就没辙了只能把应用构建在不稳定模块上呢介绍一款maven插件——versions这是一个非常强大的版本管理插件其中有个对依赖版本加锁的特性——lock-snapshots并且提供了参数可以控制锁定的依赖就可以实现对特定的SNAPSHOT模块锁定版本执行的命令如下mvn versions:lock-snapshots -DincludesListgroupId:artifactId:type:classifier:version执行这个命令之后对应的版本号会变化比如1.0.0-SNAPSHOT会变成1.0.0.20090327.172306-4即完成了锁定此时这个SNAPSHOT就变成了固定小版本的稳定版本不会在变化了也相当于正式版的功能了。当然以后也可以解锁详细请看对应文档。转载http://yongpoliu.com/snapshot-vs-release/
