世界顶尖运动队教练的成功秘诀
本文列出了来自于顶级教练Marc Lammers的9条原则，他是在打造世界最佳曲棍球队的过程中发现这些原则的，文章把这些原则映射到了软件开发实践之中。
新闻
辩论：Maven是正确的构建工具吗？
作者 Ryan Slobojan译者 曹云飞 发布于 2008年2月3日 下午7时19分
近来，有很多关于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思想的反面。为什么每当我要创建一个项目的时候我不得不去读他们的用户手册？我的意思是我没有办法记住这些垃圾而且他们的文档十分恶心，难以上手。Rocher还指出Grails有Maven的支持，但不是缺省的，而且他怀疑Maven最终会被Gant、Raven 或者Buildr这样的构建工具所替代。
我认为只有Java人会乐于接受象Maven这么复杂的构建系统。其他任何社区都会说“这是什么玩意？”。对于我来说，Maven就是构建系统的EJB2：过于复杂，过于工程师化而且需要一个智能的、有代码生成功能的IDE与其一起工作。
Matt Raible 针对Rocher的帖子发表了跟帖，指出了两个主要问题，并且对问题提出了潜在的解决方案：
- 糟糕的中心仓库元数据 —— 如果依赖是基于用户反馈而确定的，那么仓库的元数据会干净很多
- 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？
查看英文原文：Debate: Is Maven the right tool for builds?
相关厂商内容
上手难，但入门之后就比较平坦了
发表人
Ford Guo
发表于
2008年2月3日 下午8时37分
Maven一点都不难
发表人
凡 童
发表于
2008年2月4日 上午12时10分
Re: Maven一点都不难
发表人
cao yunfei
发表于
2008年2月4日 下午7时18分
Re: Maven一点都不难
发表人
avatar blogbin
发表于
2008年2月5日 上午9时49分
Re: Maven一点都不难
发表人
gem fox
发表于
2008年2月6日 下午7时31分
Re: Maven一点都不难
发表人
陈 山
发表于
2008年7月23日 上午1时53分
Matt Raible
发表人
Xiaogang Guo
发表于
2008年2月4日 上午8时19分
7 条回复
回复