324

另一个以 Java 为目标的构建工具真正带给我什么？

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

4

9 回答 9

248

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

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

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，但在我看来，您是否不只是将已知问题换成未知问题还有待观察。布丁的证据在于吃，所以我会保留判断，直到产品更成熟一点，其他人已经解决了任何问题（他们称之为出血边缘是有原因的）。不过，我仍然会在我的玩具项目中使用它，了解这些选项总是好的。

于 2009-07-22T14:11:52.050 回答
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 的轻松过渡路径。

于 2009-10-07T23:44:24.443 回答
64

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

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

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

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

Gradle 是我还没有使用过的最可配置和最灵活的构建工具。学习 DSL 和配置等概念需要预先投入一些资金，但如果您需要一个严肃且完全可配置的 JVM 构建工具，那么它很难被击败。

于 2011-12-28T04:23:16.893 回答
49

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

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

构建.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"
}
于 2010-05-02T15:35:03.210 回答
35

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

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

于 2010-07-06T00:40:58.080 回答
21

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

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

于 2012-11-02T19:52:13.817 回答
16

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

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

  • groovy 对于 java 开发者来说非常直观
  • 文档非常棒
  • 灵活性是无穷的

现在，我每天都在尝试想出新功能以添加到我们的构建过程中。这病得有多严重？

于 2012-05-23T19:07:59.037 回答
8

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

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

于 2012-01-23T20:09:57.653 回答
3

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

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

于 2012-11-24T10:31:38.593 回答