辩论：Maven 是正确的构建工具吗？

近来，有很多关于 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 与其一起工作。

Rocher 还指出 Grails 有 Maven 的支持，但不是缺省的，而且他怀疑 Maven 最终会被 Gant 、 Raven 或者 Buildr 这样的构建工具所替代。 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 少，学习成本高，强制用它的目录结构，与 IDE 集成不好，配置麻烦
robbin —— 所以我从不用 Maven，最多用点 ant
Readonly —— 共享类库可以用 IDE reference project 解决，公司内部项目给常用的 lib 建立一个 project，从 CVS 上 check out，其他工程项目都依赖这个 project 就可以了，ant build 也直接引用这个项目的 jar 就可以，项目体积照样只有几百 K。
ray_linn —— Maven 非常难搞，俺承接了一个老外的项目后期，结果就是它~ 就是它~MAVEN，不断的报告某个库找不道（明明在服务器上），最后老外和俺都失去调试 MAVEN 的兴趣，大家和平分手。Remote team 用 Maven ，万一对方是在俄罗斯或者南美洲就死掉了。靠的，为什么不能是 visualstudio 的 project file?
alexma —— 我们是 Maven 和 Ant 配合用，主要用 Maven 的依赖管理，其他 build 过程全部用 ant 完成。就我个人的使用经验，Maven 依赖管理还是挺好用的。
dlee —— 对比一下：Maven 跟 Ant 的关系，SVN 跟 CVS 的关系，可以下结论说，Maven 是个失败者。Maven 确实是让人讨厌的一个东西，笨重、学习成本 高、完全技术化的思考方式。自称是一个优秀的项目管理工具，但是除了极度狂热的技术 Fans，估计没有人愿意使用它来做项目管理。Ant 的 XML 脚本很多 时候做事情都没有 bash+sed+find 等 Unix 工具用起来快捷。我们以前做的自动化安装脚本全部使用 bash。 bash 和这些工具在 Windows 上也可以用。M$ 直到 bash 诞生将近 20 年之后（bash 的祖先 Bourne Shell 诞生 30 多年之后）才捣鼓出来了一个较为像样的 PowerShell。
jasongreen —— 多么好的依赖管理啊，我甚至把 javascript 也打到 jar 包里，用 maven 来管理，真是太方便了。当然，maven 的插件是少了点。不过这么好的东西，插件自然会慢慢多起来。
dengyin2000 —— 好用。 用它的 eclipse wtp 插件。
koalant —— mvn idea:idea , mvn eclipse:eclipse 可以生成对应 ide 的工程文件, 尤其是在 intellij 中, 通过内置的 maven 插件, 直接 debug Jetty:run , 连 tomcat 都不用了.

你如何看待 Maven？

<pre id="line41"><strong> 查看英文原文：</strong><a href="http://www.infoq.com/news/2008/01/maven-debate" id="gus2" title="Debate: Is Maven the right tool for builds?">Debate: Is Maven the right tool for builds?</a>  <br></br>