maven-javaeye

第一：举例说，你有个一依赖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。

參考來源：

"第一：举例说，你有个一依赖A用到了spring-2.0.5；后来spring在仓库换地方了（这种事情太多了，看看maven混乱的仓库吧），而你需要的是最新的spring2.5.1，那么你编译的时候就会同时有一堆spring2.0.5的文件和spring2.5的文件；那么你需要手动的排除2.0.5的相关资源。问题是在maven体系里面，这种情况非常常见，大量的依赖混在一起的时候，你看着mvn install之后lib文件夹下乱七八糟的jar真是欲哭无泪啊，很多jar是同一个库的不同的版本，这些版本的依赖可能还不同，导致问题进一步的恶化。"
- 关于Maven，不吐不快。 - develop - JavaEye论坛 (在「Google 網頁註解」中檢視)