（转）关于maven，做错的十件事

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