gradle基础入门

1. gradle简介

Java世界中主要有三大构建工具：Ant、Maven和Gradle。经过几年的发展，Ant几乎销声匿迹、Maven也日薄西山，而Gradle的发展则如日中天。

1.1. ANT

ANT是最早的构建工具，其主要基于IDEA，在2000年的时候最流行java构建工具，虽然对工程构建过程中的过程控制特别好，也比较灵活，但是它的XML脚本编写格式让XML文件特别大。

1.2. Maven

Maven主要是用来填补Ant的坑的，Maven第一次支持了从网络上下载的功能，仍然采用xml作为配置文件格式，其主要专注的是依赖管理，主要好处是它的生命周期。虽然接连的多个项目生命周期相同，这是以灵活性为代价的。 Maven也面临着依赖管理的一些问题。它不会在同一库版本之间处理好矛盾，复杂的定制构建脚本实际上Maven比ANT更难写。

1.3. Gradle

Grale是一个自动化的构建工具，Gradle属于结合以上两个的优点，它继承了Ant的灵活和Maven的生命周期管理，它最后被google作为了Android御用管理工具。它最大的区别是不用XML作为配置文件格式，采用了DSL格式，使得脚本更加简洁。Gradle引入了基于Groovy语言的DSL语法来代替XML配置，因此它的配置文件是一个Groovy文件。

2. gradle功能特性

• 基于声明的构建和基于约定的构建

Gradle 的核心在于基于 Groovy 的丰富而可扩展的域描述语言(DSL)。 Groovy 通过声明性的语言元素将基于声明的构建推向下层，你可以按你想要的方式进行组合。 这些元素同样也为支持 Java， Groovy，OSGi，Web 和 Scala 项目提供了基于约定的构建。 并且，这种声明性的语言是可以扩展的。你可以添加新的或增强现有的语言元素。 因此，它提供了简明、可维护和易理解的构建。

• 为以依赖为基础的编程方式提供语言支持

声明性语言优点在于通用任务图，你可以将其充分利用在构建中. 它提供了最大限度的灵活性，以让 Gradle 适应你的特殊需求。

• 构建结构化

Gradle 的灵活和丰富性最终能够支持在你的构建中应用通用的设计模式。 例如，它可以很容易地将你的构建拆分为多个可重用的模块，最后再进行组装，但不要强制地进行模块的拆分。 不要把原本在一起的东西强行分开（比如在你的项目结构里），从而避免让你的构建变成一场噩梦。 最后，你可以创建一个结构良好，易于维护，易于理解的构建。

• 深度 API

Gradle 允许你在构建执行的整个生命周期，对它的核心配置及执行行为进行监视并自定义。

• Gradle 的扩展

Gradle 有非常良好的扩展性。 从简单的单项目构建，到庞大的多项目构建，它都能显著地提升你的效率。 这才是真正的结构化构建。通过最先进的增量构建功能，它可以解决许多大型企业所面临的性能瓶颈问题。

• 多项目构建

Gradle 对多项目构建的支持非常出色。项目依赖是首先需要考虑的问题。 我们允许你在多项目构建当中对项目依赖关系进行建模，因为它们才是你真正的问题域。 Gradle 遵守你的布局。

Gradle 提供了局部构建的功能。 如果你在构建一个单独的子项目，Gradle 也会帮你构建它所依赖的所有子项目。 你也可以选择重新构建依赖于特定子项目的子项目。 这种增量构建将使得在大型构建任务中省下大量时间。

• 多种方式管理依赖

不同的团队喜欢用不同的方式来管理他们的外部依赖。 从 Maven 和 Ivy 的远程仓库的传递依赖管理，到本地文件系统的 jar 包或目录，Gradle 对所有的管理策略都提供了方便的支持。

• Gradle 是第一个构建集成工具

Ant tasks 是最重要的。而更有趣的是，Ant projects 也是最重要的。 Gradle 对任意的 Ant 项目提供了深度导入，并在运行时将 Ant 目标(target)转换为原生的 Gradle 任务(task)。 你可以从 Gradle 上依赖它们(Ant targets)，增强它们，甚至在你的 build.xml 上定义对 Gradle tasks 的依赖。Gradle 为属性、路径等等提供了同样的整合。

Gradle 完全支持用于发布或检索依赖的 Maven 或 Ivy 仓库。 Gradle 同样提供了一个转换器，用于将一个 Maven pom.xml 文件转换为一个 Gradle 脚本。Maven 项目的运行时导入的功能将很快会有。

• 易于移植

Gradle 能适应你已有的任何结构。因此，你总可以在你构建项目的同一个分支当中开发你的 Gradle 构建脚本，并且它们能够并行进行。 我们通常建议编写测试，以保证生成的文件是一样的。 这种移植方式会尽可能的可靠和减少破坏性。这也是重构的最佳做法。

• Groovy

Gradle 的构建脚本是采用 Groovy 写的，而不是用 XML。 但与其他方法不同，它并不只是展示了由一种动态语言编写的原始脚本的强大。 那样将导致维护构建变得很困难。 Gradle 的整体设计是面向被作为一门语言，而不是一个僵化的框架。 并且 Groovy 是我们允许你通过抽象的 Gradle 描述你个人的 story 的黏合剂。 Gradle 提供了一些标准通用的 story。这是我们相比其他声明性构建系统的主要特点。 我们的 Groovy 支持也不是简单的糖衣层，整个 Gradle 的 API 都是完全 groovy 化的。只有通过 Groovy才能去运用它并对它提高效率。

• The Gradle wrapper

Gradle Wrapper 允许你在没有安装 Gradle 的机器上执行 Gradle 构建。 这一点是非常有用的。比如对一些持续集成服务来说。 它对一个开源项目保持低门槛构建也是非常有用的。 Wrapper 对企业来说也很有用，它使得对客户端计算机零配置。 它强制使用指定的版本，以减少兼容支持问题。

• 自由和开源

Gradle 是一个开源项目，并遵循 ASL 许可。

3. gradle安装

3.1. windows安装

• 进入gradle官网：https://gradle.org，点击【Install Gradle】
• 进入页面后，可以看到installing manually手动安装，有binary-only和complete两种安装包，complete完整一些，包括文档和相应的源。
• 这里我选择了binary-only下载，下载并解压到自己想要的目录，这里我解压到我的D目录：D:\
• 添加环境变量GRADLE_HOME和path，如下所示

GRADLE_HOME:D:\F:\TEST\gradle-6.1-bin\gradle-6.1
path:%GRADLE_HOME%\bin

• 添加环境变量完成后，打开cmd命令模式，输入gradle -v，若展示gradle基本信息，则表明安装成功

3.2. gradle目录简介

gradle的目录其实与maven的目录结构是一致的，大体如下所示：

其中：

• build.gradle 用于配置当前项目的Gradle构建脚本
• gradle-wrapper.jar Gradle Wrapper可执行JAR
• gradle-wrapper.properties Gradle Wrapper配置属性
• gradlew 基于Unix的系统的Gradle Wrapper脚本
• gradlew.bat 适用于Windows的Gradle Wrapper脚本
• settings.gradle 用于配置Gradle构建的Gradle设置脚本

3.3. 新建gradle项目

3.3.1. 第一种方式

直接使用命令的方式进行创建。

• 创建一个空文件夹并进入目录
• 依次输入如下命令:gradle init
  • 选择项目的类型
  • 选择要使用的语言
  • 选择测试框架
  • 选择脚本编写的语言
  • 输入项目名称、包名，默认是我们刚才进入的文件夹名称 ,即可。

3.3.2. 第二种方式

使用工具直接创建，在IEDA中配置gradle后创建项目。

• File=>Settings=>Build,Execution,Deployment=>Builid Tools=>Gradle路径下配置如下：

• 然后新建一个gradle项目
• 然后填入指定的groupId和artifactId后完成创建,目录如下。

4. gradle构建基础

gradle构建中的两个基本概念是项目（project）和任务（task），每个构建至少包含一个项目，项目中包含一个或多个任务。在多项目构建中，一个项目可以依赖于其他项目；类似的，任务可以形成一个依赖关系图来确保他们的执行顺序。

4.1. gradle构建生命周期

Gradle的构建生命周期分为初始化，配置，执行三个阶段。

4.1.1. 初始化阶段

初始化阶段主要是读取settings.gradle 文件，用于确定哪些项目参与构建，并创建Project实例；如多个项目构建时，通常setting.gradle内容如下：

include "projectA","projectB","projectC"
//表示参与构建的项目有projectA,projectB,projectC

4.1.2. 配置阶段

配置阶段主要是为每个项目的build.gradle文件配置project对象；主要是生成task的依赖关系跟执行图。

4.1.3. 执行阶段

执行阶段主要是根据gradle命令和传入的参数创建并执行任务。

4.2. gradle任务

Gradle构建脚本描述一个或多个项目。每个项目都由不同的任务组成。任务是构建执行的一项工作，主要包括任务动作和任务依赖，任务动作定义了一个最小的工作单元，可以定义依赖，动作序列和执行条件；Gradle保证这些任务按其依赖项的顺序执行，并且每个任务只执行一次。这些任务可以抽象成一个有向无环图。Gradle会在执行任务之前构建完整的依赖关系图，这就是Gradle的核心思想。

4.2.1. 定义任务

任务是构建脚本build.gradle中的关键字，任务的定义模式大体如下所示：

task testTask{
    doLast {
        println ‘I am a tester‘
    }
}

#doLast 语句可以使用快捷方式（表示符号 <<）来简化此任务

#上述语句等同于：

task testTask << {
        println ‘I am a tester‘
}

如下，在终端中输入如下命令执行task

gradle -q testTask

4.2.2. 任务依赖

要将一个任务依赖另一个任务，在开始这个任务之前，先完成依赖的任务。 每个任务都使用任务名称进行区分。

任务的依赖第一种填写方式，我们可以直接在定义任务是指定需要依赖的任务，其中需要注意如下两点：

• 被依赖的任务可以定义在之前或者之后
• 如果被依赖的任务定义在之后，也叫做延迟依赖，延迟依赖下，被引用的的任务名需要加入引号，所以通常我们把引号加上就好了

task testTask  {
    doLast {
        println ‘I am a tester‘
    }
}
//被依赖的任务可以定义在之前或者之后
//如果被依赖的任务定义在之后，也叫做延迟依赖，
//延迟依赖下，被引用的的任务名需要加入引号，所以通常我们把引号加上就好了
task testDepend(dependsOn:‘testTask‘)  {
    doLast {
        println ‘I do test job‘
    }
}

如下，在终端中输入如下命令执行任务：

gradle -q testDepend

依赖的第二种填写方式，分别编写完任务后，在末尾写入依赖语句：

task testTask  {
    doLast {
        println ‘I am a tester‘
    }
}
task testDepend  {
    doLast {
        println ‘I do test job‘
    }
}
testDepend.dependsOn testTask

如下，在终端中输入如下命令执行任务：

gradle -q testDepend

4.2.3. 定位任务

如果要查找在构建文件中定义的任务，则必须使用相应的标准项目属性。这意味着每个任务都可以作为项目的属性，使用任务名称作为属性名称。

如下在build.gradle中定义了一个任务xiong，那么我们可以通过如下方式查找任务

task xiong

println xiong.name
println project.xiong.name

如下，在终端中输入如下命令执行任务：

gradle -q xiong

当然我们也可以由其任务集合(tasks)来查找。要引用另一个项目中的任务，应该使用项目路径作为相应任务名称的前缀。

task xiong
println tasks.xiong.name
println tasks[‘xiong‘].name

如下，在终端中输入如下命令执行任务：

gradle -q xiong

4.3. gradle依赖管理

Gradle构建脚本定义了构建项目的过程; 每个项目包含一些依赖项和一些发表项。依赖性意味着支持构建项目所需要的东西，比如构建时需要的jar包等。发布表示项目的结果，如测试类文件和构建文件，如war文件。

4.3.1. 依赖管理

如下是一个依赖管理简要图，其流程主要为：

1. 依赖管理器读取到配置文件build.gradle中需要的依赖项时
2. 先查看缓存或者本地没有指定的依赖项
3. 如果没有，则通过网络去指定的远程仓库进行下载
4. 下载后的依赖将保存在本地仓库
5. 如果依赖多次使用，则会存储在依赖缓存中

传递依赖

B依赖A，如果C依赖B，那么C依赖A。

几乎所有的基于JVM的软件项目都需要依赖外部类库来重用现有的功能。自动化的依赖管理可以明确依赖的版本，可以解决因传递性依赖带来的版本冲突。

版本冲突

如下hibermate-core-3.6.3.Final.jar依赖的hibermate-core-3.2.0.Final.jar包中依赖了slf4i-api-1.5.8.jar，所以按传递依赖的性质，hibermate-core-3.6.3.Final.jar会依赖slf4i-api-1.5.8.jar

而hibermate-core-3.6.3.Final.jar本身又依赖了slf4i-api-1.6.1.jar，所以会导致版本冲突

但是因为gradle默认会依赖最高版本的jar包，所以gradle默认是不会出现版本冲突的，

4.3.2. 声明依赖关系

在gradle中，一个group、name、version确定一个唯一的jar包，如在build.gradle文件中配置如下依赖，定义了两个依赖项，一个是Hibernate core 3.6.7，第二个是Junit 4.0和更高版本。

• Hibernate core 3.6.7用于编译时需要依赖的项
• Junit 4.0和更高版本用于测试编译时需要依赖的项

dependencies {
    compile group: ‘org.hibernate‘, name: ‘hibernate-core‘, version: ‘3.6.7.Final‘
    testCompile group: ‘junit‘, name: ‘junit‘, version: ‘4.+‘
}

4.3.3. 依赖阶段配置

依赖关系配置只是定义了一组依赖关系，然后我们根据指定的依赖声明从Web下载外部依赖关系。如下是依赖阶段不同的标准配置：

• compile:编译------编译项目的生产源所需的依赖关系。
• runtime:运行时------运行时生产类所需的依赖关系。 默认情况下，还包括编译时依赖项。
• testCompile:测试编译------编译项目测试源所需的依赖项。 默认情况下，它包括编译的产生的类和编译时的依赖。
• testRuntime:测试运行时------运行测试所需的依赖关系。 默认情况下，它包括运行时和测试编译依赖项。

4.3.4. 外部依赖

依赖的类型有很多种，其中有一种类型称之为外部依赖。这种依赖由外部构建或者储存在不同的仓库中，例如 Maven 中央仓库或 Ivy 仓库中抑或是本地文件系统的某个目录中。

如下就定义了一个外部依赖，在进行构建时会从仓库中去查找该依赖：

dependencies {
    compile group: ‘org.hibernate‘, name: ‘hibernate-core‘, version: ‘3.6.7.Final‘
}

外部依赖包含 group，name 和 version 几个属性。根据选取仓库的不同，group 和 version 也可能是可选的。

当然，也有一种更加简洁的方式来声明外部依赖。采用：将三个属性拼接在一起即可。"group:name:version"

dependencies {
    compile ‘org.hibernate:hibernate-core:3.6.7.Final‘
}

4.3.5. 存储库配置

在添加依赖关系时， Gradle在存储库中查找它们。 存储库只是文件的集合，按group，name和version来组织构造; 默认情况下，Gradle不定义任何存储库，我们必须至少明确地定义一个存储库。如下我们先定义了一个自定义的maven仓库，然后是本地的maven仓库，最后是maven的中央仓库，在查找依赖时依次从上到下进行查找。

repositories {

//自定义maven仓库，也就是maven私服
    maven {
        url:‘xxxx‘
    }
    mavenLocal()   //本地仓库
    mavenCentral() //公共仓库-maven中央仓库

jcenter()       //公共仓库-jcenter仓库
}

4.3.6. 多项目构建

在企业项目中，包层次和类关系比较复杂，把代码拆分成模块通常是最佳实践，这选哟清晰的划分功能边界，比如把业务逻辑和数据持久化拆分开来，项目符合高内聚低耦合时，模块化就不安的很容易，这是也是多项目的由来。

4.3.7. 发布文件

依赖管理配置也被用于发布文件我们称之为打包发布或发布。

插件对于打包提供了完美的支持，所以通常而言无需特别告诉 Gradle 需要做什么。但是你需要告诉 Gradle 发布到哪里。这就需要在 uploadArchives 任务中添加一个仓库。

发布到 Maven 仓库你需要 Maven 插件的支持，当我们使用：gradle uploadArchives 命令时，Gradle 构建并上传你的 jar 包，同时产生 pom.xml 一起上传到下方指定的maven仓库。

apply plugin: ‘maven‘
uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file://localhost/xxx/")
        }
    }
}

当我们使用：gradle uploadArchives 命令时，Gradle 便会构建并上传你的 jar 包，同时会生成一个 ivy.xml 一起上传到如下指定的ivy仓库：

uploadArchives {
    repositories {
        ivy {
            credentials {
                username "username"
                password "password"
            }
            url "http://repo.mycompany.com"
        }
    }
}

4.4. grale插件

Gradle 在它的核心中有意地提供了一些小但有用的功能，用于在真实世界中的自动化。所有有用的功能，例如以能够编译 Java 代码为例，都是通过插件进行添加的。插件都认为是被应用，通过 Project.apply() 方法来完成。

4.4.1. Java插件

Java 插件向一个项目添加了 Java 编译、 测试和 bundling 的能力。它是很多其他 Gradle 插件的基础服务。

Java 插件定义了两个标准的源集，分别是 main 和 test。main 源集包含你产品的源代码，它们将被编译并组装成一个 JAR 文件。test 源集包含你的单元测试的源代码，它们将被编译并使用 JUnit 或 TestNG 来执行。

在build.grale文件中Java插件的引入如下所示：

apply plugin: ‘java‘

如上是使用短名称的方式，我们也可以使用完整的名称方式：

apply plugin: org.gradle.api.plugins.JavaPlugin

或者

apply plugin: JavaPlugin

同时Java 插件向你的项目添加了大量的任务，具体可参考官网或者地址:

https://www.w3cschool.cn/gradle/q9bp1hum.html

4.4.2. groovy插件

Groovy 的插件继承自 Java 插件并添加了对 Groovy 项目的支持。它可以处理 Groovy 代码，以及混合的 Groovy 和 Java 代码，甚至是纯 Java 代码（尽管我们不一定推荐使用）。该插件支持联合编译，可以任意地混合及匹配 Groovy 和 Java 代码各自的依赖。例如，一个 Groovy 类可以继承自一个 Java 类，而这个 Java 类也可以继承自一个 Groovy 类。这样一来，我们就能够在项目中使用最适合的语言，并且在有需要的情况下用其他的语言重写其中的任何类。

其在build.gradle文件中的添加方法如下：

apply plugin: ‘groovy‘

同样groovy插件也向Project中添加了大量的任务，具体请参考官网或者地址：

https://www.w3cschool.cn/gradle/q9bp1hum.html

4.4.3. war插件

War 的插件继承自 Java 插件并添加了对组装 web 应用程序的 WAR 文件的支持。它禁用了 Java 插件生成默认的 JAR archive，并添加了一个默认的 WAR archive 任务。

apply plugin: ‘war‘

同样war插件也向Project中添加了大量的任务，具体请参考官网或者地址：

https://www.w3cschool.cn/gradle/q9bp1hum.html

4.4.4. jetty插件

Jetty 插件继承自 War 插件，并添加一些任务，这些任务可以让你在构建时部署你的 web 应用程序到一个 Jetty 的 web 嵌入式容器中。

apply plugin: ‘jetty‘

同样jetty插件也向Project中添加了大量的任务，具体请参考官网或者地址：https://www.w3cschool.cn/gradle/xg9o1hu7.html

5. gradle构建命令

原文地址：https://www.cnblogs.com/wendyw/p/12202356.html