aboug maven2

今天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。