http://flashing.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 flashing 作者: flashing  链接：http://flashing.javaeye.com/blog/162217  发表时间: 2008年02月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天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。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

]]> Thu, 14 Feb 2008 13:08:19 +0800 http://flashing.javaeye.com/blog/162217 http://flashing.javaeye.com/blog/162217