为什么选择Gradle，为什么是现在？

如果你曾经与构建系统打过交道，那么在回想你所面临的挑战时，挫败感可能是其中一种感受。构建工具不是应该自然而然地帮助你实现项目自动化的目标吗？相反，你不得不在可维护性、可用性、灵活性、可扩展性或性能方面做出妥协。

假设你在构建一个项目的发布版本时，你要把一个文件拷贝到指定的位置，你在项目的元数据那里添加了版本的描述，如果版本号匹配一个特定的数字时，就把文件从 A 拷贝到 B 处。如果你依赖 XML 来构建，你要实现这个任务就像噩梦一样，你只能通过非标准的机制来添加一些脚本到构建中，结果就是把 XML 和脚本混在一起，随着时间的推移，你会添加越来越多的自定义的代码，结果就是项目越来越复杂很难维护。为什么不考虑用表达式的语言来定义你的构建逻辑呢？

另外一个例子，Maven 跟随约定优于配置的规范，引入了标准化的项目布局和构建生命周期，给很多项目确保一个统一的结构这是个不错的方法。然而你手上的项目刚好和传统的约定不一样。Maven 的一个严格的约定就是每个项目都要生成一个 artifact，比如 jar 文件，但是你怎么从同一个源代码结构中创建两个不同的 JAR 文件，因此你不得不分开创建两个项目。

这些只是您在使用现有解决方案时可能遇到的部分问题。通常情况下，你不得不牺牲一些非功能性需求来模拟企业的自动化领域。说了这么多负面的东西，让我们来看看 Gradle 是如何融入构建工具领域的。

Java构建工具的发展

最早出现的是 Ant，Ant 里的每一个任务（target）都可以互相依赖，Ant 的最大缺点就是依赖的外部库也要添加到版本控制系统中，因为 Ant 没有一个机制来把这些 jar 文件放在一个中央库里面，结果就是不断的拷贝和粘贴代码。

随后 Maven 在2004年出现了，Maven 引入了标准的项目和路径结构，还有依赖管理，不幸的是自定义的逻辑很难实现，唯一的方法就是引入插件。

随后 Ant 通过 Apache Ivy 引入依赖管理来跟上 Maven 的脚步，Ant 和 Ivy 集成实现了声明式的依赖，比如项目的编译和打包过程。

Figure 1. 图 2.1 Gradle 结合了其他构建工具的最佳功能。

Gradle 的出现满足了很多现在构建工具的需求，Gradle 提供了一个 DSL(领域特定语言)，一个约定优于配置的方法，还有更强大的依赖管理，Gradle 使得我们可以抛弃 XML 的繁琐配置，引入动态语言 Groovy 来定义你的构建逻辑。

为什么要选择Gradle

假如你是一个开发者，项目自动构建是你每天工作的一部分，难道你就不想让你的构建代码和你写的源代码一样可以扩展、测试和维护？Gradle 的构建脚本是声明式的、可读的，可以清晰的表达意图。使用 Groovy 代替 XML 来写代码大大减少了构建代码的大小。更重要的是，Gradle 集成了其他构建工具，比如 Ant 和 Maven，使得原来的项目很容易迁徙到 Gradle。

令人印象深刻的是，要实现同样的目标，在 Gradle 中需要编写的代码要少得多。有了Gradle，你不必再做出妥协。Maven 等其他构建工具的项目布局都是 "我行我素"，而 Gradle 的 DSL 允许灵活地适应非常规的项目结构。

Gradle 的座右铭是 “让不可能成为可能，让可能变得简单，让简单变得优雅”（改编自 Moshé Feldenkrais 的引言）。

Maven

<project
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mycompany.app</groupId>
    <artifactId>my-app</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

Gradle

apply plugin: 'java'
group = 'com.mycompany.app'
archivesBaseName = 'my-app'
version = '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.11'
}

你是说永远不会改变正在运行的系统？你的团队已经花了很多时间来建立项目的构建代码基础架构。Gradle 不会强迫你完全移植现有的构建逻辑。与 Ant 和 Maven 等其他工具的良好集成是 Gradle 的首要任务。我们将在第 9 章深入探讨 Gradle 的集成特性和潜在的迁移策略。

市场似乎正在关注 Gradle。2010 年春，Gradle 荣获最具创新性开源项目 Springy 奖（ http://www.springsource.org/node/2871 ）。ThoughtWorks 是一家备受推崇的软件开发咨询公司，它定期发布有关新兴技术、语言和工具的报告，即所谓的技术雷达。技术雷达的目的是帮助软件行业的决策者了解发展趋势及其对市场的影响。在 2013 年 5 月发布的最新一期报告（ http://thoughtworks.fileburst.com/assets/technology-radar-may-2013.pdf ）中，Gradle 被评为 "采用"（Adopt）状态，表明该技术应该被业界采用。

ThoughtWorks 的认可

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

Gradle 很早就找到了采用者，甚至在 1.0 版本发布之前。 Groovy 和 Hibernate 等流行的开源项目完全转向 Gradle 作为其构建的骨干。每个 Android 项目都将 Gradle 作为默认构建系统。 Gradle 也对商业市场产生了影响。 Orbitz、EADS 和 Software AG 等公司也采用了 Gradle，仅举几例。 Spring 和 Grails 背后的公司 VMware 在选择 Gradle 方面投入了大量资金。他们的许多软件产品，例如 Spring 框架和 Grails，实际上都是建立在 Gradle 可以提供的信任之上的。