近来，有很多关于Maven的有用性的辩论。Maven是一个基于Java的构建和依赖管理工具，应用在很多项目中。InfoQ深入调查了这个辩论以理解当前的问题是什么以及辩论得出了什么结果。

Apache Tapestry和Apache HiveMind的创建者Howard Lewis Ship最近发表了一篇博文 ，在其中他描述了在他目前正在做的一个项目使用Maven碰到的一些问题：

在Eclipse和IDEA中，Maven都是非常缓慢、bug多而且不稳定的。IDEA 7比Eclipse（带有0.0.12Maven插件）好一点点，因为前者的同步功能是很直接的。然而，要让Maven工作，看起来需要没完没了的调整、修补和祈祷。
Maven在核心有一个伟大的思想（真正很好地解决依赖管理的问题），但是采用了一个非常糟糕的插件系统来执行构建。令人痛苦之处是，一个在星期一工作的好好的构建可能在星期二失败，原因是有新的、破损的插件被发布到中心Maven仓库。

Ship还说明了缺乏文档是理解和使用Maven的一个主要障碍，他推荐使用Ivy作为候选的依赖管理系统。Eugene Kuleshov 指出将插件版本号加入Maven的pom.xml文件可以解决破损插件的问题，而Charles Miller 回应说在Maven的用户或者安装指南中都没有这个建议。

Don Brown最近也他创建了一个新的Maven构建，解决了他在Maven 2中发现的一些问题，包括加入HTTP连接池和并行制品下载。在Maven的这个分支上工作正在进行着，这些变化有希望重新整合进入主干版本中。

还有很多人加入了这场辩论中，Jonas Fagundes质疑为什么Grails不用Maven，并且评论：

Maven是一个奇妙的工具，我们希望每种语言都有这样的工具。它是一个模块化项目构建工具。它能够管理依赖、构建周期、测试、 打包并且在仓库中发布你的制品。它是一个项目构建工具，领先于通常的构建工具（实际上它的第一个版本是在Ant之上的一层）。它为你的项目提供了一个缺省 的路径布局，这些缺省路径真的很美妙，你开始需要做的仅仅是选择一个名称来创建你的项目和缺省包。所有其它的事情都已准备停当，如果你的需要有所不同，你 可以提供配置，在后者情况下你可以提供一个新的被maven仓库所管理的插件（插件只是另外一种依赖，在你配置了你的pom文件之后，插件会被自动下 载）。它早在rails社区提出惯例优于配置这个术语之前就采用了该策略。

G2One的CTO，Graeme Rocher 回应了Fagundes并且说明了为什么Grails不使用Maven，他说Grails的主要思想是简化Java EE：

现在Maven完全是Grails思想的反面。为什么每当我要创建一个项目的时候我不得不去读他们的用户手册？我的意思是我没有办法记住这些垃圾而且他们的文档十分恶心，难以上手。
我认为只有Java人会乐于接受象Maven这么复杂的构建系统。其他任何社区都会说“这是什么玩意？”。对于我来说，Maven就是构建系统的EJB2：过于复杂，过于工程师化而且需要一个智能的、有代码生成功能的IDE与其一起工作。

Matt Raible 针对Rocher的帖子发表了跟帖，指出了两个主要问题，并且对问题提出了潜在的解决方案：

1. 糟糕的中心仓库元数据 —— 如果依赖是基于用户反馈而确定的，那么仓库的元数据会干净很多
2. POM.xml是项目元数据的来源 —— XML和pom.xml的啰嗦语法使得构建难以解析，用其他格式（如Groovy）来指定项目元数据，这样会简单一些
   

Raible补充道：

我仍然是一个Maven的粉丝，主要是因为他极大的简化了AppFuse的维护和发行工作。当我将来做GWT、Seam或者 Grails开发的时候，我会尝试使用Maven来做开发工作。为什么？因为我已经学会了如何使用Maven而且我没有感到其他人谈到的痛苦。我认为在真 正的大型项目（例如产生超过30个WAR的构建）中Maven真的很炫。在真正的大型项目中，一个基于Ant的系统会变得难以承受而且难于维护。不仅如 此，而且用Ant是非常难以维护一个模块化的构建系统（你可以构建/测试/部署一个单独的WAR）的。根据我的经验，真正大的基于Ant的系统总是处理那 些最新的东西，而基于Maven的系统各个部分之间是互相依赖的，需要你保持它们最新。Maven的确需要你更聪明一些并在你的子项目上运行“mvn install”，但是我宁愿这样也不愿意等5分钟来让Ant仅仅为了运行一个测试而处理所有的事情。

其他一些意见：

• boomtown15 —— 我难以相信人们这么容易放弃Maven。如果你遵循惯例，它实际上很简单的。我承认，建立第一个项目有点困难，我也同意学习曲线有一点陡峭，但是我相信益处超过这些问题。
• Xavier Hanin —— 那么，我是一个Maven的拥护者么？是也不是。我喜欢Maven的思想，能够用一种标准的方式来构建一个项目真的很棒。我不喜欢的地方是缺乏文档、灵活性和鲁棒性，而且Maven有太多的巫术。
• Les —— [……]我一直惊讶于这些对maven的攻击。Maven学习曲线的开始部分比较高，但是当事情变得更复杂的时候工作就简单了。
• Tech Per —— 我同意maven过于复杂，过于工程师化而且缺乏好的文档，但是我仍然有一个感觉，maven是最好的构建工具。我每天用maven，是的，我埋怨 maven。我也曾尝试回头使用ant（我对ant也非常了解），……使用ant是一种痛苦。所以，我发现了我从maven得到了多少益处。
  
• Ortwin —— 我们现在使用Ant来构建大型项目，因为维护一个Ｍaven构建需要太多的时间和知识。虽然Ant构建不是非常简单，但是至少它不总是崩溃。下一次我会使用Bash脚本。用XML编程的所有这些都不方便
  
• Steve —— Netbeans的Maven支持领先于所有我所见过的IDE。我在中等大小的项目中每天使用Maven，它给项目带来了很多好处，我无法想象失去它会怎 样。学习如何驯服Maven的确需要一些投资，但是一旦你掌握了你会发现Maven是最好的。依赖管理、基于目的的简介、理解构建生命周期阶段，小心你增加的是什么仓库，这些都是驯服这头野兽的关键。
• Kevin Menard —— 依我愚见，快照系统不起作用。正常使用快照的时候，项目可以让早期的使用者用快照来做测试，这是一个伟大的方法。但是，它经常出问题，成为阻碍正式版本的障碍。
• distiller —— [……]我过去宣传Maven，但是现在成为一个Ivy的倡导者。Ivy在你如何建立你的仓库方面比Maven灵活的多，因为构建工作委托给Ant了，所以Ivy不象Maven那样试图规定你的项目结构
• Jay —— [Howard Lewis Ship]，你的意见是成立的，我已经象你一样被Maven整了很多次 —— 下载破损的版本，明显错误的文档，等等，但是有什么选择？请给我一个惯例优于配置、依赖管理并且有丰富插件的工具，我会考虑的。在目前阶段，精力应该被用 于解决你提出的问题（文档问题特别糟糕）而不是从头开始。
  
• Jon Scott Stevens —— [……] 下面仅供参考……我们已经面试了许多申请Java开发者职位的人，许多人都说了maven的优点。
• Peter Backlund —— Maven是一个非常有用的工具，我已经在很多项目中使用了它，效果很好。你需要适应Maven的哲学，否则你可能会很惨。如果你的态度是“这是我组织一 个项目的方式，现在我要让Maven适应我的方式！”，你会处于悲惨世界中。如果你与Maven好好相处，你会免费得到很多好处。
• Matt Raible —— 我不认为所有人都认为Maven是一个坏主义 —— 它是一个好主义的坏实现。
• Rick Hightower ——我每天诅咒Maven。我每天赞美Maven。我对它是爱恨交加。虽然Maven本可以做得更好，但是使用Ant简直就是梦魇。我旅行了很多地方，做 了很多咨询/开发工作……我看到了太多打结的Ant构建脚本。至少用maven，我只需要驯服一头野兽和顺从一个哲学。用Ant，那简直就是随时出现的有 很多头的野兽。
  
• Bryan Taylor —— Maven中确实有一些革新的思想，但是它也有一些令我害怕的东西。早在Ruby on Rails风潮之前，Maven依靠的就是“惯例优于配置”的思想，但滑稽的是RoR被公认为是这个思想的发明者。这是有原因的。
  

在国内技术社区JavaEye上，也有许多关于maven的争论 ：

daquan198163 —— Maven N宗罪：在公司内开发项目时，类库定下来后，为了稳定基本也不会升级了，所以它的最大优势体现不出来，需要搭建私服，简直没事找事儿插件比Ant少，学习成本高，强制用它的目录结

　1　2

如果图片或页面不能正常显示请点击这里