关于maven,做错的十件事

java maven

maven管理的java项目越来越多,令人遗憾的是在使用maven的时候,多多少少都会遇到这样那样的问题,于是会有各种各样的解决办法,下面是一个列表,列出了使用maven的误区和解决办法。 1.频繁在所有项目使用mvn install并且随时在更新 这是我见过的最常见的问题,解决了这个问题有许多的好处。在maven的文档中找不到一句对这种情况的描述,不过我坚信一句话:每个artifact在maven仓库中都有一个家。
在你的公司里,应该有一个仓库管理工具。每一个你开发的模块都应该发布到这个仓库上去。你可能会问,应该什么时候发布?答案是,每次在你的构建服务器构建之后,都需要发到仓库。我们通常都使用Hudson来做这件事情,另外还有ContinuumTeamCity也还不错。

现在,当你所有的项目都在仓库里有的时候,你的项目就不再需要不断地mvn install了。如果你修改一个模块,你只需要重建这个模块,其余依赖的模块会由maven自动从仓库中下载。

2.你和你的团队成员依靠复制.m2文件夹来解决项目里的依赖找不到的问题 这看起来很疯狂,不过这件事情经常发生。解决的办法,设置一名仓库管理员。一旦管理好了仓库,就不会再出现大家找u盘复制.m2文件夹的事情了。因为可以加速,你不应该把本地的仓库整个地删除掉,毕竟在本地读取仓库是最快的。

3. 你为了解决依赖找不到一个老版本构件的问题,把最新的pom文件修改了版本弄到了老文件里后安装 考虑到这种情况,有人把一个模块的版本从1.3-SNAPSHOT修改成了1.4-SNAPSHOT。你马上要去度假,所以呢你就不想再更新和安装1.3的版本了,而你的模块正好要依赖1.3版本的那个模块,你如何去弄到老的版本呢?嗯,你可以到处找找,在代码库里找到了这个模块的最新代码,而且版本还是1.3的,你更新了这个版本号并且进行了安装。或者你还可以把你的代码从1.4弄到1.3去,安装并祈祷能够正常工作。

我想上面的解决办法都不是很好,同样,你的公司需要一个代码仓库管理员,如果有一次1.3-SNAPSHOT成功的构建,那就应该在仓库里存在一份,问题解决。

4. 你有许多shell脚本或者是批处理文件,它们通过你的模块的target文件来产生一个zip文件 maven有方法专门做这件事情,叫做“assemblies”。他们不是最容易安装的,但是一旦你安装好了,将与maven完全无缝结合,这要比许多山寨自制的脚本要平滑得多。这些山寨的脚本有许多的问题,比如说版本开始改变,模块被移动等等。

5.你有许多的xml在pom里,目的只是复制文件到发布时的文件夹去,而且它不成很好的工作,也不轻便 这和4正好是对立的,maven看上去不是为了复制文件而构建。如果你想复制你的包(诸如war,ear,zip文件),写一个ant shell bat文件都会很简单完成。

6.你在build的时候总是呆在“checking for updates from xxx-repo”而你不知道什么原因 这是一个很让有些人很气愤的事情,往往花费太多时间去找问题所在。也许这个事情正好可以让你去喝杯咖啡。尽管如此,这个问题的一些通常原因,就是你有一个快照版本的依赖,并且在你的pom文件中有一堆的仓库列表。maven不关心哪个包去哪个仓库里取,所以看上去是从所有的仓库里更新所有的包。
如果你配置了你的maven安装时到指定的仓库里去寻找所有的包(在settings.xml里设置mirror),maven会只到这个仓库里寻找。当这个服务器在本地,将得到加速。用上仓库管理很重要,

7.如果你在release分支上写代码,你的trunk的构建将会失败(或者说是1.0-SNAPSHOT应该对所有人来说都是好用的) 有许多事情你应该记住,当给你的项目创建一个分枝的时候。其中之一是告诉你的构建服务器,并且其他模块需要修改版本为你的pom的声明。如果你忽略随后才做这事,当你想修改了分支里的代码又想在主干里开发时,你会遇到问题。
这里有一个goal在发布插件里,叫做“branch”,靠运行“mvn release:branch”,maven可以为你自动重命名pom文件里的版本号。(免责声明,我还没试过这个命令。。。目前我经常只在创建了一个release的时候才打分支,在“mvn release:perform”后使用“mvn release:prepare”)

8.整个公司内容的依赖都是以-SNAPSHOT结束 快照对开发者来说很舒服,它几乎要完成了,但是迟早,你应该要停下你的脚步,发送你的包给世人,或者是你的同事。一直呆在快照版本有许多的问题。首先它减慢了你的构建速度。因为maven不得不去检查最后的快照是不是在更新了。其次,如果你的项目依赖于一个快照版本,你很难判断是依赖哪个版本的快照。构建可能会失败,只是因为你拿到了一个更新的快照。
如果你依赖一个公司内部的模块,并且这个模块目前是好用的,那么修改所有的依赖为非快照版本后才发布,是一个不错的主意。这样我们才能知道,即使有家伙还在那个模块上疯狂写代码的时候,你的模块依旧可以构建通过,因为它依赖的是一个稳定的发布。

9.跑一下“mvn dependency:analyze”,没有使用和没有使用的依赖列表很长 这个很BT,但不知道准确依赖很危险。最大的问题是maven的传递依赖。

10.当有人发布了你使用的新版本的插件,你的构建就挂了 maven的插件不必写上版本,maven会找到最好的版本。当有新版本的插件的时候,你不必知道就会下载使用最新的。有时候,最好的判断不总是正确。根据经验,越新的越有bug。因此,明码标价写上你使用的插件的版本是有意义的


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明

Comments