1.1 Gradle的优势

• 一款最新的，功能最强大的构建工具，用它逼格更高

• 使用Groovy或Kotlin代替XML，使用程序代替传统的XML配置，项目构建更灵活

• 丰富的第三方插件，让你随心所欲使用

• 完善Android,Java开发技术体系

1.2 Gradle的下载和安装

下载位置：Gradle Distributions

PS：下载只有二进制文件的即可（bin那个压缩包）

1.3 配置环境变量

配置GRADLE_HOME：

配置Path：

验证Gradle是否安装成功：

1.4 创建第一个Gradle项目

标准项目结构：

项目打包：

执行：

如果出现乱码，在builde.gradle中加入配置：（更改后重新clean再build）

plugins {id 'java'
}
​
group 'com.msb'
version '1.0-SNAPSHOT'
​
repositories {mavenCentral()
}
​
dependencies {testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
}
​
test {useJUnitPlatform()
}
​
tasks.withType(JavaCompile) {options.encoding = "UTF-8"
}

PS:

1.5 build.gradle构建脚本介绍

Gradle构建脚本中最重要的两个概念是project和Task,任何一个Gradle构建都由一个或者多个project组成每个project包括许多的构建部分,可以是一个jar包,也可以是一个web应用,也可以是多个jar的整合,可以部署应用和搭建环境.

如果有子项目的话：

每个项目，对应一个build.gradle的构建脚本

1.5.1 Project

一个project代表一个正在构建的组件(Jar/war文件)，当构建开始时，Gradle会基于build.gradle实例化一个org.gradle.api.Project对象，并通过project变量来隐式调用其成员。

Project属性：

将build.gradle配置封装为一个Project对象，对象名字为project，通过project可以隐式调用：使用groovy语法

指定仓库位置：默认情况下使用的是中央仓库，此项目如果需要下载jar包从中央仓库中下载到本地目录（C:/Users/zss/.gradle）
mavenCentral()
下载后的内容可以去：C:\Users\zss\.gradle\caches\modules-2\files-2.1中找
但是一般我们习惯使用maven本地仓库：
需要设置maven本地仓库：

进行环境变量设置：

重启IDEA打开，如果需要重新设置maven本地库位置：

PS：本地仓库的设置对新建项目是生效的

如果需要添加依赖，可以从中央仓库中查找坐标：

粘贴过来以后，点击刷新：

build.gradle中内容：

plugins {id 'java'
}
​
project.group = 'com.msb'
version '1.0-SNAPSHOT'
/*
指定仓库位置：默认情况下使用的是中央仓库，此项目如果需要下载jar包从中央仓库中下载到本地目录（C:/Users/zss/.gradle）
mavenCentral()
下载后的内容可以去：C:\Users\zss\.gradle\caches\modules-2\files-2.1中找
但是一般我们习惯使用maven本地仓库：
需要设置maven本地仓库：
*/
repositories {mavenLocal()mavenCentral()
}
​
dependencies {testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'// https://mvnrepository.com/artifact/org.mybatis/mybatisimplementation group: 'org.mybatis', name: 'mybatis', version: '3.5.9'
​
}
​
test {useJUnitPlatform()
}
​
tasks.withType(JavaCompile) {options.encoding = "UTF-8"
}

PS:Gradle没有自己的中央仓库，用的就是maven的中央仓库

1.5.2 Task

每个任务在构建执行过程中会被封装成org.gradle.api.Task对象，主要包括任务的动作和任务依赖，任务动作定义了一个原子操作，可以定义依赖其他任务、动作的顺序、执行的条件。

任务主要操作动作： dependsOn：依赖相关操作 doFirst ：任务执行之前执行的方法 doLast、<<（老版本用，现在废弃了）：任务执行之后执行的方法

定义好任务后，默认分配在other分组下：

也可以放在自定义的分组下：

任务的定义的方式：（6种定义方式）

plugins {id 'java'
}
​
project.group = 'com.msb'
version '1.0-SNAPSHOT'
/*
指定仓库位置：默认情况下使用的是中央仓库，此项目如果需要下载jar包从中央仓库中下载到本地目录（C:/Users/zss/.gradle）
mavenCentral()
下载后的内容可以去：C:\Users\zss\.gradle\caches\modules-2\files-2.1中找
但是一般我们习惯使用maven本地仓库：
需要设置maven本地仓库：
*/
repositories {mavenLocal()mavenCentral()
}
​
dependencies {testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'// https://mvnrepository.com/artifact/org.mybatis/mybatisimplementation group: 'org.mybatis', name: 'mybatis', version: '3.5.9'
​
}
​
test {useJUnitPlatform()
}
​
tasks.withType(JavaCompile) {options.encoding = "UTF-8"
}
​
//自定义任务：
//定义方式1：
task(t1,{group("mytask")//配置代码println '我是任务1'//动作代码doFirst {println '在任务t1执行前操作的动作代码'}//动作代码doLast {println '在任务t1执行后操作的动作代码'}
})
//定义方式2：
task t2 {group("mytask")//配置代码println '我是任务2'//动作代码doFirst {println '在任务t2执行前操作的动作代码'}//动作代码doLast {println '在任务t2执行后操作的动作代码'}
}
​
//定义方式3：
tasks.create('t3'){group("mytask")//配置代码println '我是任务3'
}
​
//定义方式4：
tasks.register('t4'){group("mytask")//配置代码println '我是任务4'
}
​
//定义方式5：
tasks{task t5{group("mytask")//配置代码println '我是任务5'}
}
​
//可以一次性定义多个任务-》动态任务定义：
3.times{index ->task("task${index}"){group("mytask")//配置代码println 'task${index}'}
}

任务依赖：

//任务依赖：
task a{doFirst {println '我是任务a'}
}
​
task b(dependsOn:a){//代表b任务依赖a任务--->依赖方式通过参数传递doFirst {println '我是任务b'}
}
​
task c{dependsOn 'b'  //依赖方式通过内部设置方式进行依赖doFirst {println '我是任务c'}
}
​
task d{doFirst {println '我是任务d'}
}
​
d.dependsOn c   //依赖方式通过外部设置方式进行依赖

任务的执行时机：

在构建阶段，配置代码是不执行的，在执行阶段，执行动作代码

//通过tasks.register定义的任务，在build阶段的配置过程中不执行
//通过tasks.register定义的任务，在任务的执行阶段的配置过程中是执行的
//通过tasks.register定义的任务，配置代码的执行时机是落后于用task方式配置的

定位任务：对某个已有的任务进行扩展：例如对clean内置任务进行扩展

clean.doLast {println '我在clean之后执行这个逻辑'
}
​
tasks.named('clean').get().doFirst {println '我在clean之前执行这个逻辑'
}

1.6 Gradle项目构建生命周期

Gradle的生命周期分三个阶段：初始化阶段、配置阶段,、执行阶段。 初始化阶段 通过settings.gradlle判断有哪些项目需要初始化，加载所有需要初始化的项目的build.gradle文件并为每个项目创建project对象 配置阶段 执行各项目下的build.gradle脚本，完成project 的配置，并且构造Task任务依赖关系图以便在执行阶段按照依赖关系执行Task中的配置代码 执行阶段 通过配置阶段的Task图，按顺序执行需要执行的任务中的动作代码，就是执行任务中写在doFirst或doLast中的代码。

1.7 插件

1.7.1 添加插件、发布和使用自定义jar包

案例：将自己的项目打成jar包，供给另外的项目使用

（1）新建一个Gradle项目：

（2）配置插件：

（3）然后刷新项目，刷新后任务中多了一个分组：

（4）配置发布分组：在build.gradle中配置：

(5)执行任务，发布jar包到本地仓库中：

（6）自行去本地库中查找你jar包和生成的配置文件：

C:\Users\zss.m2\repository\org\example\TestGradleJar

（7）在其它项目中使用刚才本地库中的jar包：

（8）验证：是否可以使用jar包中内容：

1.7.2 自定义插件

（1）在构建脚本中直接编写自定义插件：

但是上面的方法只能在当前脚本中使用，不可以在整个项目中使用，如果要想在整个项目中的所有构建脚本中都使用的话，需要将任务单独提取出来放入buildSrc下：

（2）自己创建buildSrc目录：

注意点：groovy目录创建好后一定要是蓝色的文件夹，如果是灰色的文件夹，需要自己构建build.gradle脚本，然后加入插件：

然后定义插件：

定义好以后，就可以在项目的所有build.gradle中使用了：

1.8 Gradle版本冲突问题

（1）依赖传递性：

假设你的项目依赖于一个库，而这个库又依赖于其他库。你不必自己去找出所有这些依赖，你只需要加上你直接依赖的库，Gradle会隐式的把这些库间接依赖的库也加入到你的项目中。

（2）传递性依赖中版本冲突：

由于传递性依赖的特点，两个不同版本的jar包会被依赖进来，这样就存在版本冲突的问题。

（3）maven中解决冲突的办法-自动解决方案：

【1】第一原则：最短路径优先原则

“最短路径优先”意味着项目依赖关系树中路径最短的版本会被使用。

例如，假设A、B、C之间的依赖关系是A->B->C->D(2.0) 和A->E->(D1.0)，那么D(1.0)会被使用，因为A通过E到D的路径更短。

【2】第二原则：最先声明原则

依赖路径长度是一样的的时候，第一原则不能解决所有问题，比如这样的依赖关系：A–>B–>Y(1.0)，A–>C–>Y(2.0)，Y(1.0)和Y(2.0)的依赖路径长度是一样的，都为2。那么到底谁会被解析使用呢？在maven2.0.8及之前的版本中，这是不确定的，但是maven2.0.9开始，为了尽可能避免构建的不确定性，maven定义了依赖调解的第二原则：第一声明者优先。在依赖路径长度相等的前提下，在POM中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优胜。

（4）Gradle中解决冲突的办法-自动解决方案：

Gradle的默认自动解决版本冲突的方案是选用版本最高的。

案例：加入两个依赖：

implementation group: 'org.springframework', name: 'spring-jdbc', version: '5.1.3.RELEASE'
implementation group: 'org.springframework', name: 'spring-webmvc', version: '5.1.13.RELEASE'
​

（5）Gradle中解决冲突的办法-手动修改依赖：

手动排除依赖：

dependencies { implementation(group: 'org.springframework', name: 'spring-jdbc', version: '5.1.3.RELEASE'){exclude group:'org.springframework',module:'spring-beans'}
}

后续可以自己手动配置你想要的版本的依赖。

修改默认配置策略，对所有jar不做冲突自动解决：

configurations.all{resolutionStrategy{failOnVersionConflict()}
}

就会在构建时候抛出异常：

手动指定某个jar 的版本：

force:强制覆盖某个版本：

configurations.all{resolutionStrategy{force 'org.springframework:spring-beans:5.3.12'}
}

1.9 多项目构建

在企业中，一个复杂的项目往往是分成几个小项目来协同完成的，这就涉及到多项目的构建，而多项目构建则需要把一个大项目进行项目模块化，通过模块的互相协作完成整个功能。在之前使用Maven的多项目构建时，一般需要一个root项目来统一管理所有的模块，Gradle也一样使用一个root项目来统一管理所有的模块。

案例：

构建：

配置：

配置1：统一插件配置：在根项目的build.gradle中配置：

//统一配置信息，包含root项目：
allprojects{//写法1：
//    plugins {
//        id 'java'
//    } //写法2：apply plugin : 'java'
}

配置2：统一配置公共属性：

​
allprojects{project.group = 'com.msb'version '1.0-SNAPSHOT'
}
​

配置3：配置项目的依赖关系：在子项目的build.gradle中配置：

验证：

配置4：统一资源库：

subprojects{repositories {mavenLocal()mavenCentral()}
}

配置5：配置公用的依赖：配置在根项目的build.gradle中：

subprojects{
​dependencies {testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'}
​
}
​

PS：如果配置在subprojects外面，就只针对根生效，对子项目无效，只有放在subprojects中对所有项目生效