为什么使用Gradle而不是Ant或Maven?

我自己并没有在愤怒中使用Gradle(到目前为止只是一个玩具项目)[作者的意思是他们到目前为止只在一个玩具项目中使用过Gradle，并不是说Gradle是一个玩具项目-见评论]，但我想说的是，人们会考虑使用它的原因是Ant和Maven的挫折。

根据我的经验，Ant通常只写(是的，我知道可以写__abc，但事实是大多数人不这样做)。对于任何重要的项目来说，它都是令人费解的，并且需要非常小心地确保复杂的构建是真正可移植的。它的命令性可以导致在构建之间复制配置(尽管宏在这里可以提供帮助)。

Maven采取相反的方法，并期望您完全集成到Maven生命周期中。有经验的Ant用户会发现这一点尤其不和谐，因为Maven删除了您在Ant中拥有的许多自由。例如，有一个Sonatype博客枚举了许多Maven的批评和他们的回应。

Maven插件机制允许非常强大的构建配置，继承模型意味着您可以为整个企业定义一组父POMs，封装您的构建配置，单个项目可以继承这些配置，使它们变得轻量级。Maven配置非常冗长(尽管Maven 3承诺解决这个问题)，如果你想做任何“不是Maven方式”的事情，你必须写一个插件或使用hack Ant集成。注意，我碰巧喜欢编写Maven插件，但我知道很多人会反对所付出的努力。

Gradle有望达到Ant和Maven之间的最佳点。它使用艾薇的方法进行依赖项解析。它允许约定优于配置，但也将Ant任务作为第一类公民。它还明智地允许您使用现有的Maven/Ivy存储库。

因此，如果你遇到了Ant/Maven的任何痛点，可能值得尝试一下Gradle，尽管在我看来，如果你不只是把已知的问题换成未知的问题，还有待观察。布丁的好坏在吃的过程中才能检验，所以我会保留意见，直到产品更成熟一点，其他人解决了任何问题(他们称之为流血边缘是有原因的)。不过，我仍然会在我的玩具项目中使用它，了解这些选项总是好的。

Gradle可以用于许多目的——它是比Ant更好的瑞士军刀——但它特别专注于多项目构建。

首先，Gradle是一个依赖编程工具，这也意味着它是一个编程工具。使用Gradle，你可以在你的设置中执行任何随机任务，Gradle会确保所有声明的依赖都正确和及时地执行。您的代码可以以任何类型的布局(树形、平面、分散等)分布在许多目录中。

Gradle有两个不同的阶段:评估和执行。基本上，在评估期间，Gradle会在它应该查找的目录中查找和评估构建脚本。在执行期间，Gradle将执行在评估期间加载的任务，并考虑到任务的相互依赖性。

在这些依赖编程特性之上，Gradle通过与Apache Ivy集成增加了项目和JAR依赖特性。如你所知，Ivy是一个比Maven强大得多、不那么固执己见的依赖管理工具。

Gradle检测项目之间以及项目与jar之间的依赖关系。Gradle与Maven存储库(下载和上传)一起工作，比如iBiblio或你自己的存储库，但也支持你可能拥有的其他类型的存储库基础设施。

在多项目构建中，Gradle既能适应，又能适应构建的结构和架构。您不必像使用Maven那样根据构建工具调整结构或体系结构。

Gradle非常努力地不妨碍你，而Maven几乎从不这样做。惯例很好，灵活性也很好。Gradle提供了比Maven更多的特性，但最重要的是，在许多情况下，Gradle将为您提供从Maven过渡到Maven的轻松路径。

Gradle很好地结合了Ant和Maven，从这两个框架中取其精华。来自Ant的灵活性和来自Maven的约定优于配置、依赖管理和插件。

因此，如果你想要一个标准的java构建，比如在maven中，但测试任务必须执行一些自定义步骤，它可能如下所示。

build.gradle:

apply plugin:'java'
task test{
doFirst{
ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
}
doLast{
...
}
}

最重要的是，它使用groovy语法，它提供了比ant/maven的xml更强大的表达式。

它是Ant的超集——你可以用更好的、类似groovy的语法在gradle中使用所有Ant任务。

ant.copy(file:'a.txt', toDir:"xyz")

或

ant.with{
delete "x.txt"
mkdir "abc"
copy file:"a.txt", toDir: "abc"
}

我们使用Gradle，而不是Maven和Ant。Ant为我们提供了完全的灵活性，Ivy提供了比Maven更好的依赖关系管理，但是对多项目构建的支持并不好。您最终需要编写大量代码来支持多项目构建。此外，使用一些按约定构建的方法也很好，可以使构建脚本更加简洁。使用Maven，它按照约定进行构建太过了，自定义构建过程变成了一种hack。此外，Maven促进了发布工件的每个项目。有时，您将一个项目划分为子项目，但您希望所有子项目一起构建并进行版本控制。Maven并不是专门为这个目的设计的。

使用Gradle，你可以拥有Ant的灵活性，并按照Maven的约定进行构建。例如，用您自己的任务扩展传统的构建生命周期是很简单的。如果你不愿意，也不用强制使用约定。Groovy比XML更适合代码。在Gradle中，您可以在本地文件系统上定义项目之间的依赖关系，而不需要将每个项目的工件发布到存储库中。最后，Gradle使用Ivy，所以它有出色的依赖管理。到目前为止，对我来说唯一真正的缺点是缺乏成熟的Eclipse集成，但是Maven的选项并没有好到哪里去。

这可能有点争议，但Gradle并没有隐藏它是一种成熟的编程语言的事实。

Ant + Ant -contrib本质上是一种图灵完整的编程语言，没有人真的想用它来编程。

Maven试图采取相反的方法，试图完全声明性，并强迫您在需要逻辑时编写和编译插件。它还强加了一个完全不灵活的项目模型。Gradle结合了所有这些工具的优点:

• 它遵循约定优于配置(类似Maven)，但仅限于您想要的程度
• 它允许您像在Ant中那样编写灵活的自定义任务
• 它提供了优于Ant和Maven的多模块项目支持
• 它有一个DSL，使80%的事情变得简单，20%的事情成为可能(不像其他构建工具使80%的事情变得简单，10%的事情成为可能，而10%的事情实际上是不可能的)。

Gradle是我使用过的最具可配置性和灵活性的构建工具。它需要一些前期投资来学习DSL和诸如配置之类的概念，但如果你需要一个没有废话且完全可配置的JVM构建工具，那么它是很难被取代的。

管理本地构建也容易得多。Ant和Maven实际上只支持java。存在一些Maven插件，试图处理一些本地项目，但它们没有有效地完成工作。可以编写Ant任务来编译本地项目，但它们太复杂和笨拙了。

我们用JNI和许多其他原生位来做Java。Gradle大大简化了我们的Ant混乱。当我们开始将依赖管理引入本地项目时，它很混乱。我们让Maven来做这件事，但等效的Gradle代码只是Maven所需要的一小部分，人们可以阅读和理解它，而不必成为Maven专家。

Gradle将乐趣带回了构建/组装软件。我的整个职业生涯都使用ant来构建软件，我一直认为开发工作中实际的“构建”部分是必要的邪恶。几个月前，我们的公司厌倦了不使用二进制回购(也就是将jar签入风投)，我被赋予了调查这个问题的任务。从常春藤开始，因为它可以拴在蚂蚁的顶部，没有太多的运气让我构建的工件像我想要的那样发布。我使用了maven和xml，在一些简单的helper库中工作得很出色，但在尝试将应用程序捆绑为部署时遇到了严重的问题。我花了很长时间在谷歌上搜索插件，阅读论坛，最后下载了数万亿的支持插件，我很难使用这些插件。最后我选择了gradle(在这一点上我变得非常痛苦，并为“它不应该这么难!”而烦恼)

但从第一天起，我的情绪开始好转。我有进展了。我花了大约两个小时来迁移我的第一个ant模块，而构建文件基本上什么都没有。易于安装一个屏幕。大的“哇”是:在xml中构建脚本，这是多么愚蠢啊?事实上，声明一个依赖需要一行非常吸引我->你可以很容易地在一个页面上看到某个项目的所有依赖。从那时起，我一直在不停地滚动，到目前为止，我遇到的每一个问题都有一个简单而优雅的解决方案。我认为原因如下:

groovy对于Java开发人员来说非常直观
• 文档非常棒 灵活性是无限的

现在，我每天都在努力想出新功能来添加到我们的构建过程中。这有多恶心?

这不是我的的答案，但它确实引起了我的共鸣。它来自ThoughtWorks 2012年10月推出的技术雷达:

有两件事导致人们对Ant和 Maven:太多愤怒的尖括号和插件的粗糙 架构。而语法问题可以通过 生成、插件体系结构严重限制了构建的能力 随着项目变得更加复杂，工具可以优雅地增长。我们来了 认为插件是错误的抽象级别，并且更喜欢 而是像Gradle和Rake这样的基于语言的工具，因为它们提供 更细粒度的抽象和更大的长期灵活性

我在一定程度上同意Ed Staub的观点。与maven相比，Gradle无疑更强大，从长远来看也提供了更多的灵活性。