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

Why use Gradle instead of Ant or Maven?

提问by IttayD

What does another build tool targeted at Java really get me?

另一个针对 Java 的构建工具对我有什么帮助？

If you use Gradle over another tool, why?

如果您在其他工具上使用 Gradle，为什么？

采纳答案by Rich Seller

I don't use Gradlein anger myself (just a toy project so far) [author means they have used Gradle on only a toy project so far, not that Gradle is a toy project - see comments], but I'd say that the reasons one would consider using it would be because of the frustrations of Ant and Maven.

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

In my experience Ant is often write-only (yes I know it is possible to write beautifully modular, elegant builds, but the fact is most people don't). For any non-trivial projects it becomes mind-bending, and takes great care to ensure that complex builds are truly portable. Its imperative nature can lead to replication of configuration between builds (though macros can help here).

根据我的经验，Ant 通常是只写的（是的，我知道可以编写精美的模块化、优雅的构建，但事实是大多数人不这样做）。对于任何非平凡的项目，它都会变得令人费解，并且非常小心地确保复杂的构建真正具有可移植性。它的命令性质会导致构建之间的配置复制（尽管宏在这里可以提供帮助）。

Maven takes the opposite approach and expects you to completely integrate with the Maven lifecycle. Experienced Ant users find this particularly jarring as Maven removes many of the freedoms you have in Ant. For example there's a Sonatype blogthat enumerates many of the Maven criticisms and their responses.

Maven 采取相反的方法，并希望您与 Maven 生命周期完全集成。有经验的 Ant 用户会发现这特别刺耳，因为 Maven 取消了您在 Ant 中拥有的许多自由。例如，有一个Sonatype 博客列举了许多 Maven 批评及其回应。

The Maven plugin mechanism allows for very powerful build configurations, and the inheritance model means you can define a small set of parent POMs encapsulating your build configurations for the whole enterprise and individual projects can inherit those configurations, leaving them lightweight. Maven configuration is very verbose (though Maven 3 promises to address this), and if you want to do anything that is "not the Maven way" you have to write a plugin or use the hacky Ant integration. Note I happen to like writing Maven plugins but appreciate that many will object to the effort involved.

Maven 插件机制允许非常强大的构建配置，而继承模型意味着您可以定义一小组父 POM，为整个企业封装您的构建配置，单个项目可以继承这些配置，使它们保持轻量级。Maven 配置非常冗长（尽管 Maven 3 承诺解决这个问题），如果你想做任何“不是 Maven 方式”的事情，你必须编写一个插件或使用 hacky Ant 集成。请注意，我碰巧喜欢编写 Maven 插件，但感谢许多人会反对所涉及的工作。

Gradle promises to hit the sweet spot between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens. It also wisely allows you to use existing Maven/Ivy repositories.

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

So if you've hit and got stuck with any of the Ant/Maven pain points, it is probably worth trying Gradle out, though in my opinion it remains to be seen if you wouldn't just be trading known problems for unknown ones. The proof of the pudding is in the eating though so I would reserve judgment until the product is a little more mature and others have ironed out any kinks (they call it bleeding edge for a reason). I'll still be using it in my toy projects though, It's always good to be aware of the options.

因此，如果您遇到并被任何 Ant/Maven 痛点所困扰，那么可能值得尝试 Gradle，但在我看来，如果您不只是将已知问题换成未知问题，还有待观察。布丁的证据在于吃，所以我会保留判断，直到产品更成熟一些，其他人已经解决了任何问题（他们称之为流血边缘是有原因的）。不过，我仍然会在我的玩具项目中使用它，了解这些选项总是好的。

回答by Steven Devijver

Gradle can be used for many purposes - it's a much better Swiss army knife than Ant - but it's specifically focused on multi-project builds.

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

First of all, Gradle is a dependency programming tool which also means it's a programming tool. With Gradle you can execute any random task in your setup and Gradle will make sure all declared dependecies are properly and timely executed. Your code can be spread across many directories in any kind of layout (tree, flat, scattered, ...).

首先，Gradle 是一个依赖编程工具，这也意味着它是一个编程工具。使用 Gradle，您可以在设置中执行任何随机任务，Gradle 将确保所有声明的依赖项都正确且及时地执行。您的代码可以以任何类型的布局（树状、扁平状、分散状……）分布在许多目录中。

Gradle has two distinct phases: evaluation and execution. Basically, during evaluation Gradle will look for and evaluate build scripts in the directories it is supposed to look. During execution Gradle will execute tasks which have been loaded during evaluation taking into account task inter-dependencies.

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

On top of these dependency programming features Gradle adds project and JAR dependency features by intergration with Apache Ivy. As you know Ivy is a much more powerful and much less opinionated dependency management tool than say Maven.

在这些依赖编程特性之上，Gradle 通过与 Apache Ivy 的集成添加了项目和 JAR 依赖特性。如您所知，与 Maven 相比，Ivy 是一个更强大、更不固执的依赖管理工具。

Gradle detects dependencies between projects and between projects and JARs. Gradle works with Maven repositories (download and upload) like the iBiblio one or your own repositories but also supports and other kind of repository infrastructure you might have.

Gradle 检测项目之间以及项目和 JAR 之间的依赖关系。Gradle 可以使用 Maven 存储库（下载和上传），例如 iBiblio 或您自己的存储库，但也支持您可能拥有的其他类型的存储库基础架构。

In multi-project builds Gradle is both adaptable and adapts to the build's structure and architecture. You don't have to adapt your structure or architecture to your build tool as would be required with Maven.

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

Gradle tries very hard not to get in your way, an effort Maven almost never makes. Convention is good yet so is flexibility. Gradle gives you many more features than Maven does but most importantly in many cases Gradle will offer you a painless transition path away from Maven.

Gradle 非常努力地不妨碍您，这是 Maven 几乎从未做过的努力。惯例很好，但灵活性也很好。Gradle 为您提供了比 Maven 多得多的功能，但最重要的是，在许多情况下，Gradle 将为您提供一条远离 Maven 的轻松过渡路径。

回答by piotrga

Gradle nicely combines both Ant and Maven, taking the best from both frameworks. Flexibility from Ant and convention over configuration, dependency management and plugins from Maven.

Gradle 很好地结合了 Ant 和 Maven，充分利用了这两个框架的优点。来自 Ant 的灵活性和来自 Maven 的配置、依赖管理和插件的约定。

So if you want to have a standard java build, like in maven, but test task has to do some custom step it could look like below.

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

build.gradle:

构建.gradle：

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

On top of that it uses groovy syntax which gives much more expression power then ant/maven's xml.

最重要的是，它使用 groovy 语法，比 ant/maven 的 xml 提供更多的表达能力。

It is a superset of Ant - you can use all Ant tasks in gradle with nicer, groovy-like syntax, ie.

它是 Ant 的超集 - 您可以使用 gradle 中的所有 Ant 任务，使用更好的、类似 groovy 的语法，即。

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

or

或者

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

回答by BCK

We use Gradle and chose it over Maven and Ant. Ant gave us total flexibility, and Ivy gives better dependency management than Maven, but there isn't great support for multi-project builds. You end up doing a lot of coding to support multi-project builds. Also having some build-by-convention is nice and makes build scripts more concise. With Maven, it takes build by convention too far, and customizing your build process becomes a hack. Also, Maven promotes every project publishing an artifact. Sometimes you have a project split up into subprojects but you want all of the subprojects to be built and versioned together. Not really something Maven is designed for.

我们使用 Gradle 并选择它而不是 Maven 和 Ant。Ant 为我们提供了完全的灵活性，而 Ivy 提供了比 Maven 更好的依赖项管理，但对多项目构建的支持并不好。您最终需要进行大量编码以支持多项目构建。也有一些构建的约定很好，使构建脚本更简洁。使用 Maven，按照惯例进行构建太过分了，而自定义构建过程就变成了一种黑客行为。此外，Maven 会促进每个发布工件的项目。有时，您将一个项目拆分为多个子项目，但您希望将所有子项目一起构建和版本化。Maven 并不是真正为之设计的。

With Gradle you can have the flexibility of Ant and build by convention of Maven. For example, it is trivial to extend the conventional build lifecycle with your own task. And you aren't forced to use a convention if you don't want to. Groovy is much nicer to code than XML. In Gradle, you can define dependencies between projects on the local file system without the need to publish artifacts for each to a repository. Finally, Gradle uses Ivy, so it has excellent dependency management. The only real downside for me thus far is the lack of mature Eclipse integration, but the options for Maven aren't really much better.

使用 Gradle，您可以拥有 Ant 的灵活性并按照 Maven 的约定进行构建。例如，使用您自己的任务扩展传统的构建生命周期是微不足道的。如果您不想，也不会被迫使用约定。Groovy 比 XML 更适合编码。在 Gradle 中，您可以在本地文件系统上定义项目之间的依赖关系，而无需将每个项目的工件发布到存储库。最后，Gradle 使用 Ivy，因此它具有出色的依赖项管理。到目前为止，对我来说唯一真正的缺点是缺乏成熟的 Eclipse 集成，但 Maven 的选项并没有好多少。

回答by omnisis

This may be a bit controversial, but Gradle doesn't hide the fact that it's a fully-fledged programming language.

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

Ant + ant-contrib is essentially a turing complete programming language that no one really wants to program in.

Ant + ant-contrib 本质上是一种没有人真正想要编程的图灵完备的编程语言。

Maven tries to take the opposite approach of trying to be completely declarative and forcing you to write and compile a plugin if you need logic. It also imposes a project model that is completely inflexible. Gradle combines the best of all these tools:

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

• It follows convention-over-configuration (ala Maven) but only to the extent you want it
• It lets you write flexible custom tasks like in Ant
• It provides multi-module project support that is superior to both Ant and Maven
• It has a DSL that makes the 80% things easy and the 20% things possible (unlike other build tools that make the 80% easy, 10% possible and 10% effectively impossible).

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

Gradle is the most configurable and flexible build tool I have yet to use. It requires some investment up front to learn the DSL and concepts like configurations but if you need a no-nonsense and completely configurable JVM build tool it's hard to beat.

Gradle 是我尚未使用过的最可配置和最灵活的构建工具。它需要预先进行一些投资来学习 DSL 和配置等概念，但如果您需要一个严肃且完全可配置的 JVM 构建工具，它就很难被击败。

回答by swpalmer

It's also much easier to manage native builds. Ant and Maven are effectively Java-only. Some plugins exist for Maven that try to handle some native projects, but they don't do an effective job. Ant tasks can be written that compile native projects, but they are too complex and awkward.

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

We do Java with JNI and lots of other native bits. Gradle simplified our Ant mess considerably. When we started to introduce dependency management to the native projects it was messy. We got Maven to do it, but the equivalent Gradle code was a tiny fraction of what was needed in Maven, and people could read it and understand it without becoming Maven gurus.

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

回答by Kalle

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!")

Gradle 将乐趣重新投入到构建/组装软件中。在我的整个职业生涯中，我都使用 ant 来构建软件，而且我一直认为开发工作中实际的“构建”部分是必要的。几个月前，我们公司厌倦了不使用二进制存储库（也就是将 jars 签入 vcs），我被赋予了调查这个的任务。从 ivy 开始，因为它可以用螺栓固定在 ant 上，但我没有多少运气像我想要的那样发布我构建的工件。我选择了 maven 并使用 xml 进行了破解，为一些简单的帮助程序库做了出色的工作，但在尝试捆绑准备部署的应用程序时遇到了严重的问题。在谷歌搜索插件和阅读论坛上困扰了很长时间，最终为各种插件下载了数万亿个支持 jar，我很难使用这些插件。

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 scriptsin 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:

但从第一天起，我的心情就开始好转。我正在到达某个地方。我花了大约两个小时来迁移我的第一个 ant 模块，构建文件基本上什么都没有。轻松安装一个屏幕。最大的“哇”是：在 xml 中构建脚本，这有多愚蠢？声明一个依赖项需要一行这一事实对我来说非常有吸引力 -> 您可以在一页上轻松查看某个项目的所有依赖项。从那时起，我一直在不断前进，到目前为止，对于我遇到的每一个问题，都有一个简单而优雅的解决方案。我认为有以下几个原因：

• groovy is very intuitive for java developers
• documentation is great to awesome
• the flexibility is endless

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

Now I spend my days trying to think up new features to add to our build process. How sick is that?

现在，我每天都在努力想出新功能以添加到我们的构建过程中。那病到什么程度？

回答by Ed Staub

This isn't myanswer, but it definitely resonates with me. It's from ThoughtWorks' Technology Radar from October 2012:

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

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.

有两件事会导致使用基于 XML 的构建工具（如 Ant 和 Maven）感到疲劳：太多的尖括号和粗糙的插件架构。虽然语法问题可以通过生成来解决，但插件架构严重限制了构建工具随着项目变得更加复杂而优雅增长的能力。我们开始觉得插件是错误的抽象级别，而更喜欢 Gradle 和 Rake 等基于语言的工具，因为它们提供更细粒度的抽象和更大的长期灵活性。

回答by lives

I agree partly with Ed Staub. Gradle definitely is more powerful compared to maven and provides more flexibility long term.

我部分同意 Ed Staub。与 maven 相比，Gradle 绝对更强大，并提供了更大的长期灵活性。

After performing an evaluation to move from maven to gradle, we decided to stick to maven itself for two issues we encountered with gradle ( speed is slower than maven, proxy was not working ) .

在执行了从 maven 迁移到 gradle 的评估之后，我们决定坚持 maven 本身来解决我们在 gradle 中遇到的两个问题（速度比 maven 慢，代理不起作用）。