关于Maven，不吐不快。

今天infoq上一篇帖子，里面有句话说maven整个一个配置系统的EJB2，说到我心坎里了。
Maven有maven的好处，但是当你实际用起来maven之后，问题比你想象的要多的多，你很难驾驭它，这一切来自于混乱的仓库/版本/依赖管理和糟糕的ide插件支持。
我曾经发过帖子描述了我的需求和对maven的期待以及遇到的实际问题，newsmth上有个网友说我应该用maven1而不是maven2，我越核计越觉得不对劲，虽然那时我刚用maven，了解到的反对声音貌似很少，但是现在看看，随着对maven了解的增多，我也同时听到了越来越多的质疑声音。
主要的问题有如下几个：
第一：举例说，你有个一依赖A用到了spring-2.0.5；后来spring在仓库换地方了（这种事情太多了，看看maven混乱的仓库吧），而你需要的是最新的spring2.5.1，那么你编译的时候就会同时有一堆spring2.0.5的文件和spring2.5的文件；那么你需要手动的排除2.0.5的相关资源。问题是在maven体系里面，这种情况非常常见，大量的依赖混在一起的时候，你看着mvn install之后lib文件夹下乱七八糟的jar真是欲哭无泪啊，很多jar是同一个库的不同的版本，这些版本的依赖可能还不同，导致问题进一步的恶化。
第二：从eclipse的maven插件来说，add dependency的时候，一旦仓库更新了，你根本看不到最新的文件是是什么，比如struts2现在是2.0.11，但是你搜索的时候只能看到2.0.9，因为我是那个时候装的；加入了这个dependency之后只能手动改版本到2.0.11再编译。
第三：开发者们同步仍然有困难。如果项目依赖一个仓库里面没有的文件你就完蛋了，手动拷贝到本地目录是个常见做法，如果你有100个人参与项目我想你要加入一个依赖简直大家都要崩溃了，比如struts2的json插件这个包。幸好还有artifactory，不过你一遍遍的手动发到私服上也够烦了。
maven的支持者们，我们是活在现实世界中的生命，maven的思想很好但是java本身缺乏版本管理机制并且maven也没有切实有效的解决这个问题，只能靠meta里面maven文件夹里面的描述信息，这个信息很多时候没有经过严格测试的（我遇到过几次了！导致项目根本没法编译过去，那个包的开发人员一定也用的是他自己的私服）！如果再这样下去我想很多人会崩溃的……
我仍然是maven的用户，但是我在瞪着眼睛等待一个新的工具，取代maven和ant。

想想CVS …… 

89年的东东。用到2008年。

简单就是好。

maven2实际上挺好的。
用任何东西，都是双刃剑。关键要扬长避短。
1、用maven2，最好有自己的私服。
   比如，Spring 2.5.1，可能刚release，repo1.maven.org/maven2/不一定有。
   你可以install到你的私服去。
2、应该结合Ant
   很多maven不灵活的地方，可以用ant来解决
3、定义meta-inf的信息。
   开发OSGI的Bundle，就必须定义meta-inf信息。也可以定义自己的格式。
4、不要使用maven2相关的ide。
   实际上，多使用命令。比如mvn eclipse.然后，导入到eclipse工程。
   有更新，再执行mvn eclipse，在刷新工程就可以。
   我非常反对，过多的依赖IDE。单元测试比较难做，无法做到持续集成！
   题外话：我个人强烈倾向于调式，使用mvn jetty:run；
     数据库就用hsqldb,便于使用dbunit.
     毕竟，现在可以使用spring,jpa/hibernate.
     完全可以做到数据库无关性，应用服务器无关性。
5、依赖关系要设计好
   jar和jar之间的关系，package和package之间的关系，
    开发前，设计的时候就要规划好，不能什么都靠工具。工具不是万能的。
    尤其是开发OSGI bundle的时候，依赖关系一定要先设计好，
    一定要保证单向依赖性！

实际上，我使用maven，中间也遇到了一些问题，总的说来，帮助还是非常大。
尤其是，新来的开发人员搭建开发、测试环境、持续集成的时候，效果非常明显！
我也承认maven2是好的思路，但是实现得不好。
最重要的是，在新的工具出现前，我们只能选择它。
不过，可以结合IVY，ant，尽可能的扬长避短。

很好，很强大

作为一个项目的创建者，整理和配置项目的类库版本及其依赖关系是最基本的工作，Maven仅仅是一个工具，当然不能什么都依赖它。

增加类库时，我一直觉得直接修改pom最简单。对于某一个类库的版本是不是有了新的更新问题，自己去这个类库的网站看看是最好的方法。

真的想在公司内部使用maven的话，必须要安装楼主所谓的私服服务器的，至于维护这个私服服务器也不是那么困难吧，关键是搞明白maven到底能为你带来什么帮助，你去怎么利用它。

其他的不想说什么了，工具本来就是给会用工具的人使用的。

TO rasonyang:
你说的其实很有道理，但是有几个地方其实只是没有更好办法下的无奈之举。
比如meta-inf的信息，我一直认为这只是sun在java缺失了版本管理之后的一个补救而已，虽然它可以work；
至于每次mvn eclipse再刷新ide……我的确不知道可以这样，但是我想至于吗，难道plugin不应该自己来解决这个问题？
依赖ide我觉得不是错，maven是给你持续集成和管理项目用的不是给你调试用的，我调试直接用jetty的jar在eclipse里面来解决。
至于依赖关系要解决好，我实在想不出来maven如果不完美解决依赖，为什么要搞这么多乱七八糟的自动依赖……大多数时间为了保证ci可以完美运作你在配置maven的时候是消除多余依赖而不是正向添加依赖，这一点上远不如ant的方式。

TO redstarstar：
我这里只是提出问题而已，maven的思想里面，就是要自动解决依赖的，比如hibernate需要cglib或者struts-menu需要jxl------但是就是这个jxl，库里面的2.7.3这个版本就有问题，莫名带了个log4j的配置，结果日志全崩溃了，换回2.7就好了。
你所提出的前两点，都是maven在其思想下着力要解决的问题，如果没有自动正确的解决依赖，没有自动把依赖更新到最新这两点，那么我为什么不用ant呢！或者说您现在提出的只是用ant的思想来考虑maven。

ant需要自己手工做的东西太多啦，ivy没好好用过，不知道比maven2如何。
center上的依赖可不一定都满足你的要求，绝对某某版本不对，自己在私服上重新install一个自己用的就好了，加个abcd标志什么的。
对maven2最头疼的还是pom.xml太大了，还没上集成测试就50多k了，每次翻着看都头疼，又时候觉得要是能切分就好了，化整为零。

自动解决依赖啊，ivy还不是一样用的maven2的repo？也碰到过某某依赖中包含了个log4j.properties，把项目自己的日志配置都改糟了，下载源代码，重新install一个自己的版本呗。ide实在是支持的不好，幸亏我不用ide。

PS: java的jar版本一直就这么乱，没经过测试，谁也没法保证老版本的依赖换成新的能不能跑。是等java社区整理出规矩来，还是自己动手，这的确是个问题。

难道你们不觉得Maven很难用？

等待maven3出现解决问题，用netbeans的maven插件可以排除掉一些依赖的jar包