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

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

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

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

Gradle put the fun back into building/assembling software. I used ant to build software my entire career and I have always considered the actual "buildit" part of the dev work being a necessary evil. A few months back our company grew tired of not using a binary repo (aka checking in jars into the vcs) and I was given the task to investigate this. Started with ivy since it could be bolted on top of ant, didn't have much luck getting my built artifacts published like I wanted. I went for maven and hacked away with xml, worked splendid for some simple helper libs but I ran into serious problems trying to bundle applications ready for deploy. Hassled quite a while googling plugins and reading forums and wound up downloading trillions of support jars for various plugins which I had a hard time using. Finally I went for gradle (getting quite bitter at this point, and annoyed that "It shouldn't be THIS hard!")

But from day one my mood started to improve. I was getting somewhere. Took me like two hours to migrate my first ant module and the build file was basically nothing. Easily fitted one screen. The big "wow" was: build scripts in xml, how stupid is that? the fact that declaring one dependency takes ONE row is very appealing to me -> you can easily see all dependencies for a certain project on one page. From then on I been on a constant roll, for every problem I faced so far there is a simple and elegant solution. I think these are the reasons:

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

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

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的轻松路径。

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

Two things have caused fatigue with XML-based build tools like Ant and Maven: too many angry pointy braces and the coarseness of plug-in architectures. While syntax issues can be dealt with through generation, plug-in architectures severely limit the ability for build tools to grow gracefully as projects become more complex. We have come to feel that plug-ins are the wrong level of abstraction, and prefer language-based tools like Gradle and Rake instead, because they offer finer-grained abstractions and more flexibility long term.

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

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