Answers:
我不会用Gradle来激怒自己（到目前为止只是一个玩具项目）[作者表示，到目前为止，他们仅在一个玩具项目上使用Gradle，而不是Gradle是一个玩具项目-请参阅评论]，但我要说的是人们之所以考虑使用它的原因是因为Ant和Maven的挫败感。
根据我的经验，Ant通常是只写的（是的，我知道可以编写漂亮的模块化，优雅的build，但是事实是大多数人不会写）。对于任何非平凡的项目，它都会变得弯曲，并会格外小心，以确保复杂的构建真正可移植。它的命令性性质可以导致在构建之间复制配置（尽管宏可以在此提供帮助）。
Maven采用相反的方法，希望您与Maven生命周期完全集成。经验丰富的Ant用户会发现这特别令人讨厌，因为Maven消除了您在Ant中拥有的许多自由。例如，有一个Sonatype博客，列举了许多Maven批评及其回应。
Maven插件机制允许非常强大的构建配置，并且继承模型意味着您可以定义一整套父POM，将整个企业的构建配置封装起来，并且各个项目都可以继承这些配置，从而使其轻量化。Maven配置非常冗长（尽管Maven 3承诺会解决此问题），如果您想做“非Maven方式”的任何事情，则必须编写插件或使用hacky的Ant集成。请注意，我碰巧喜欢编写Maven插件，但感谢许多人反对所涉及的工作。
Gradle承诺会在Ant和Maven之间达到最佳位置。它使用Ivy的方法来解决依赖项。它允许在配置上进行约定，但还包括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的轻松过渡路径。
这可能会引起争议，但是Gradle并没有掩盖它是一种成熟的编程语言的事实。
Ant + ant-contrib本质上是一种图灵完整的编程语言，没有人真正想要编程。
Maven尝试采取相反的方法，即尝试完全声明性，并在需要逻辑时强制您编写和编译插件。它还强加了一个完全不灵活的项目模型。Gradle结合了所有这些最佳工具：
Gradle是我尚未使用的最可配置和最灵活的构建工具。要学习DSL和诸如配置之类的概念，需要先进行一些投资，但是如果您需要一个精巧且完全可配置的JVM构建工具，那么这将是无与伦比的。
Gradle很好地结合了Ant和Maven，从这两个框架中汲取了最大的优势。Ant的灵活性以及约定，配置，依赖关系管理和Maven的插件。
因此，如果您想要像在maven中那样具有标准的Java构建，但是测试任务必须执行一些自定义步骤，则它可能如下所示。
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的超集-您可以在gradle中使用更好的，类似于groovy的语法（即）使用所有Ant任务。
ant.copy(file:'a.txt', toDir:"xyz")要么
ant.with{
delete "x.txt"
mkdir "abc"
copy file:"a.txt", toDir: "abc"
}我们使用Gradle并选择了它而不是Maven和Ant。与Maven相比，Ant为我们提供了全面的灵活性，而Ivy提供了更好的依赖关系管理，但是对多项目构建没有很好的支持。您最终需要进行大量编码来支持多项目构建。还可以通过常规方式进行构建，这使构建脚本更加简洁。使用Maven时，按照常规进行构建会花费太多时间，并且自定义构建过程将成为一大难题。而且，Maven会促进每个发布工件的项目。有时，您有一个项目分解为多个子项目，但是您希望所有子项目都可以一起构建和版本控制。并不是Maven专为设计的。
使用Gradle，您可以灵活地使用Ant并按照Maven的约定进行构建。例如，通过您自己的任务来扩展传统的构建生命周期是微不足道的。如果您不想这么做，也不必强制使用约定。Groovy在代码方面比XML更好。在Gradle中，您可以定义本地文件系统上项目之间的依赖关系，而无需将每个项目的工件发布到存储库。最后，Gradle使用Ivy，因此具有出色的依赖项管理。到目前为止，对我来说，唯一真正的缺点是缺少成熟的Eclipse集成，但是Maven的选择并不是更好。
这不是我的答案，但肯定会引起我的共鸣。这是从2012年10月ThoughtWorks的技术雷达：
两件事导致了基于XML的构建工具（如Ant和Maven）的疲劳：太多恼怒的尖括号和插件体系结构的粗糙。尽管语法问题可以通过一代代来解决，但是插件体系结构严重限制了构建工具随着项目变得越来越复杂而优雅地增长的能力。我们已经感觉到插件是错误的抽象级别，而是更喜欢基于语言的工具（例如Gradle和Rake），因为它们提供了更细粒度的抽象和更长期的灵活性。
Gradle将乐趣重新投入了构建/组装软件。我在整个职业生涯中都使用ant来构建软件，而且我一直认为开发工作中实际的“ buildit”部分是必不可少的。几个月前，我们公司对不使用二进制存储库（也就是将罐子检入vcs）感到厌倦，因此我承担了调查此事的任务。从常春藤开始，因为它可以用螺栓固定在蚂蚁上，所以运气不佳就可以像我想要的那样发布我的内置工件。我去了maven，用xml破解了，为一些简单的辅助程序libs出色地工作，但是在尝试捆绑准备部署的应用程序时遇到了严重的问题。花费了相当长的时间搜索谷歌插件和阅读论坛，并且为我难以使用的各种插件下载了数万亿的支持罐。
但是从第一天起，我的情绪就开始好转。我到某处。我花了两个小时来迁移我的第一个ant模块，而构建文件基本上没有任何内容。轻松安装一个屏幕。最大的“哇”是：用xml 构建脚本，这有多愚蠢？声明一个依赖项需要一行的事实对我很有吸引力->您可以轻松地在一页上看到某个项目的所有依赖项。从那时起，我始终如一地前进，对于迄今为止我遇到的每个问题，都有一个简单而优雅的解决方案。我认为这些是原因：
现在，我花了几天的时间尝试思考要添加到构建过程中的新功能。那病得厉害