【Csdn.net 3月13日报道】不久之前博客Adam Bien写了关于一篇关于老话题：Ant或者Maven的文章，文中有写道“Maven的真正厉害之处是它的依赖管理（dependency management），要做许多工作才能让Ant的依赖管理达到Maven的程度……”文章对Maven似乎有所偏爱，这引起来了Adam Pohorecki的争论，并由此进一步谈到了Java构建工具的未来：
尽管Ant没有内置的依赖管理是个事实，但是将Ivy整合到你build.xml中还是很简单的，所以我认为Adam Bien所说的“许多工作”是个误导。
如果要我在Ant和Maven之间选择，我会选择前者。我也理解为什么很多人喜欢将Maven作为他们首选的构建工具，因为它有构建脚本，只需要几行代码来配置就可以有许多功能：依赖管理、内置的编译和打包应用的任务、与Jetty的集成、干净的项目web网址，与cobertura的集成、pmd或者findbugs。在这种情况下，如果你启动的项目非常常规（使用Spring &Hibernate的应用），Maven就是非常好的选择。
没有人想写构建脚本，因为这种代码没有任何真正的商业价值。如果没有遇到问题，你会觉得Maven真的很棒。但也许你的项目不是常规的，也许你使用的插件彼此冲突，在Maven这样的构建系统中有许多失败的地方，而且经常你很难找到它们的来源并修复它们。
Ant比Maven更值得选择的优点并不明显。而且Ant用手来编写所有的构建代码确实很遭罪。但一旦搞定之后，构建脚本就真正成了你的代码。而且在运行出现问题时，你可以检查代码并修改之，不必像无头苍蝇一样无迹可寻。
但是，Maven和Ant就只是我们的选择么？是否还有比它们更好的选择？在过去的几年中，我们看到很多项目，他们使用的工具不再使用XML来定义构建逻辑，而是真正的编程语言像Groovy、Ruby、Python，它们经常允许依赖管理。这里有几个：GRADLE 、Gant、Kundo、 Raven、 Buildr。
我最爱的构建工具是Gant，它至今也不过发布了几个月而已。Gant基本是一种Groovy的方式调用了Ant任务，比较起老旧的build.xml它有很多优点。通过使用真正的编程语言而不是XML，许多本来在XML中很是枯燥的任务变得简单：将通用代码提取为方法、循环、条件逻辑。实际上，XML并非编程语言也不应当被当成编程语言来使用。使用像Groovy或者Ruby这样的语言来构建脚本更加简洁、易懂，而且杂乱冗余的代码更少，结构上也更清晰。
在我看来，在Java环境构建自动化的未来是Gradle，或者是另外一些有相似特性的工具。Gradle是一种我所喜欢的构建脚本：如果是简单、标准的项目你只需要几行配置就可以搞定。它甚至在不使用Maven或者Ivy套件库的情况下允许可传递的依赖管理（transitive dependency management）。当我们第一次知道“依赖管理”，是用ivy.xml或者pom.xml写下我们的依赖，然后不得不安装一个独立的仓库（repository ）来存储这些不能在Maven库中找到的依赖，不得不修补pom.xml文件，因为有些没有声明它们的依赖。现在这一切可以成为历史了，我们有DM，只要在SVN库中存储我们需要的libs，然后在用到的时候转到真正的DM就可以了。
而且，如果是大的项目，除了其他特性之外Gradle拥有对多项目构建的第一类（first-class）支持，（比如你可以规定项目依赖，当你构建一个附属项目时，它的依赖也会被构建好）。Gradle还有其他很多特性，你可以在官网的用户指南上寻找，大概100多页。我的意思是如果你肯花点时间来阅读，你就会发现Gradle将会让你的开发变得多么地容易。
但我还是不得不承认，Gradle也许不适合“产品理念”，毕竟项目开发还是个新事物。但如果你想找个更好的工具来替代Ant，Gradle就是。如果你想找工具代替Maven，也许还得等几个月，因为Gradle目前还没有支持许多Maven用户所依赖的特性，比如项目网址、为主要的IDEs生成项目文档。
概括来说，虽然对自动化构建而言没有一种方法解决所有问题的解决方案，但正在进步的新工具却在努力做到这点。既可以按照惯例来构建，也可以按照你自己想要的方法来构建，Gradle在这两方面既吸引了Ant也吸引了Maven的fans。在我看来，未来构建脚本是用像Groovy或者Ruby这样的编程语言来编写的，而Gradle将在工具中占据重中之重。（译/王玉磊）
【发表评论0条】
