针对Java的另一个构建工具真的让我感到满意吗？
如果您使用Gradle而不是其他工具，为什么？
答案 0 :(得分：248)
我自己没有使用Gradle（到目前为止只是一个玩具项目） [作者意味着到目前为止他们只在玩具项目中使用过Gradle，而不是Gradle是一个玩具项目 - 看到评论] ，但我会说人们会考虑使用它的原因是因为Ant和Maven的挫折。
根据我的经验，Ant通常是只写的（是的，我知道可以编写beautifully modular, elegant build s，但事实是大多数人都不这样做。对于任何非平凡的项目，它都会变得令人费解，并且非常谨慎地确保复杂的构建真正可移植。它的命令本质可以导致在构建之间复制配置（尽管宏可以在这里提供帮助）。
Maven采用相反的方法，期望您完全与Maven生命周期集成。有经验的Ant用户发现这特别刺耳，因为Maven删除了Ant中的许多自由。例如，有一个Sonatype blog列举了许多Maven批评及其回应。
Maven插件机制允许非常强大的构建配置，继承模型意味着您可以定义一小组父POM，封装整个企业的构建配置，单个项目可以继承这些配置，使它们轻量级。 Maven配置非常冗长（尽管Maven 3承诺解决这个问题），如果你想做任何“不是Maven方式”的事情，你必须编写插件或使用hacky Ant集成。注意我碰巧喜欢编写Maven插件，但很多人会反对所涉及的工作。
Gradle承诺打到Ant和Maven之间的最佳位置。它使用Ivy的方法进行依赖性解析。它允许约定优于配置，但也包括Ant任务作为一等公民。它还明智地允许您使用现有的Maven / Ivy存储库。因此，如果你已经遇到任何Ant / Maven痛点，那么可能值得尝试Gradle，但在我看来，如果你不仅仅是为了交易已知问题还有待观察未知的。虽然布丁的证据在于吃，所以我会保留判断，直到产品稍微成熟一些，其他人已经解决了任何扭结（他们称之为出血的原因）。我仍然会在我的玩具项目中使用它，了解选项总是很好。
答案 1 :(得分：79)
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的无痛过渡路径。
答案 2 :(得分：64)
这可能有点争议，但Gradle并没有隐瞒它是一种完全成熟的编程语言这一事实。
Ant + ant-contrib本质上是一种图灵完整的编程语言，没有人真正想要编程。
Maven尝试采用相反的方法尝试完全声明，并强迫您在需要逻辑时编写和编译插件。它还强加了一个完全不灵活的项目模型。 Gradle结合了所有这些工具中的最佳工具：
Gradle是我尚未使用的最易配置且最灵活的构建工具。它需要一些投资才能学习DSL和配置等概念，但如果你需要一个没有废话和完全可配置的JVM构建工具，那就很难被击败。
答案 3 :(得分：49)
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的超集 - 你可以在gradle中使用所有Ant任务，使用更好，更像groovy的语法，即。
ant.copy(file:'a.txt', toDir:"xyz")
或
ant.with{
delete "x.txt"
mkdir "abc"
copy file:"a.txt", toDir: "abc"
}
答案 4 :(得分：35)
我们使用Gradle并在Maven和Ant上选择它。 Ant给了我们足够的灵活性，Ivy提供了比Maven更好的依赖管理，但是对多项目构建没有很大的支持。您最终会进行大量编码以支持多项目构建。还有一些build-by-convention很好，使构建脚本更简洁。使用Maven，它需要按照惯例进行构建，并且自定义构建过程会变成黑客。此外，Maven还会推广每个发布工件的项目。有时您将项目拆分为子项目，但您希望所有子项目一起构建和版本化。并不是Maven的特色。
使用Gradle，你可以拥有Ant的灵活性，并按照Maven的惯例进行构建。例如，使用您自己的任务扩展传统构建生命周期是微不足道的。如果你不愿意，你不会被迫使用约定。 Groovy的编码比XML好得多。在Gradle中，您可以在本地文件系统上定义项目之间的依赖关系，而无需将每个工件的工件发布到存储库。最后，Gradle使用Ivy，因此它具有出色的依赖管理。到目前为止，我唯一真正的缺点是缺乏成熟的Eclipse集成，但Maven的选项并没有那么好。
答案 5 :(得分：21)
这不是我的答案，但它肯定会引起我的共鸣。它来自ThoughtWorks' Technology Radar from October 2012：
基于XML的构建工具（如Ant和Ant）导致两件事情疲劳 Maven：太多愤怒的尖括号和插件的粗糙 架构。虽然可以通过处理语法问题 一代，插件架构严重限制了构建的能力 随着项目变得更加复杂，工具可以优雅地发展。我们来了 认为插件是错误的抽象级别，而且更喜欢 基于语言的工具，如Gradle和Rake，因为它们提供 更细粒度的抽象和更长期的灵活性。
答案 6 :(得分：16)
Gradle将乐趣带回建筑/组装软件。我在整个职业生涯中使用ant来构建软件，我一直认为开发工作的实际“构建”部分是必要的恶魔。几个月前，我们公司厌倦了不使用二进制仓库（也就是将罐装到vcs中），我被赋予了调查这个的任务。从常春藤开始，因为它可能被拴在蚂蚁之上，没有太多的运气，让我的建筑物像我想要的那样出版。我去了maven并用xml攻击，为一些简单的帮助库工作了很棒但我遇到了严重的问题，试图捆绑应用程序准备部署。讨厌谷歌插件和阅读论坛，并为各种插件下载了数万亿的支持罐，我很难使用。最后我去了gradle（在这一点上变得非常痛苦，并且生气地说“它应该不是那么难！”）
但从第一天开始，我的情绪开始好转。我到了某个地方。我花了两个小时来迁移我的第一个ant模块，构建文件基本上没什么。轻松安装一个屏幕。最大的“哇”是：在xml中构建脚本，这有多愚蠢？声明一个依赖关系需要一行这一事实对我来说非常有吸引力 - ＆gt;您可以在一个页面上轻松查看某个项目的所有依赖项。从那时起，我一直在不停地滚动，因为到目前为止我遇到的每一个问题都有一个简单而优雅的解决方案。我认为这些是原因：
现在，我花了很多时间尝试将新功能添加到构建过程中。这有多恶心？
答案 7 :(得分：8)
管理本机构建也更容易。 Ant和Maven实际上只是Java。一些插件存在于Maven尝试处理一些本地项目，但他们没有做有效的工作。可以编写用于编译本机项目的Ant任务，但它们过于复杂和笨拙。
我们使用JNI和许多其他本机位来做Java。 Gradle大大简化了我们的Ant混乱。当我们开始向本机项目引入依赖管理时，它很混乱。我们让Maven去做了，但是等效的Gradle代码只是Maven所需要的一小部分，人们可以在不成为Maven大师的情况下阅读并理解它。
答案 8 :(得分：3)
我同意Ed Staub的观点。与maven相比，Gradle肯定更强大，并且长期提供更大的灵活性。
在执行评估以从maven转移到gradle之后，我们决定坚持使用maven本身两个问题 我们遇到了gradle（速度比maven慢，代理无效）。