1. 本地安装 Gradle
1.1. 下载软件
官网地址：gradle.org/
这里下载二进制版本：
这里选择当前最新版本：
下载好后直接解压到目标地址即可：
注意：Gradle 是基于 Java 的，因此首先要安装 Java JDK。
1.2. 系统配置
这里主要配置下系统环境变量：
在 Path 中添加%GRADLE_HOME%\bin即可完成环境变量配置。
由于 Gradle 需要下载相关依赖包，默认是在 C 盘里面，后续可能会占用较多磁盘，因此可以增加一个环境变量的配置，修改下载下来的依赖的存储位置，可以理解成 Maven 的 localRepository 标签配置，具体如下图：
配完使用gradle -v命令查看下：
2. IDEA 配置 Gradle
2.1. 默认配置
2.2. 自定义配置
新建项目后，该界面显示如下：
3. Gradle 和 Maven 的区别
Gradle 没有自己的中央仓库，用的就是 Maven 的中央仓库。
3.1. 常用命令对比
| 命令 | Gradle | Maven |
|---|---|---|
| 构建项目 | ./gradlew build | mvn clean install |
| 清理项目 | ./gradlew clean | mvn clean |
| 运行测试 | ./gradlew test | mvn test |
| 生成项目文档 | ./gradlew javadoc | mvn javadoc:javadoc |
| 发布到远程仓库 | ./gradlew publish | mvn deploy |
| 列出项目依赖 | ./gradlew dependencies | mvn dependency:tree |
| 扫描项目依赖漏洞 | ./gradlew dependencyCheckAnalyze | mvn org.owasp:dependency-check-maven:check |
| 创建新项目 | 使用初始化插件，如 Spring Initializr | mvn archetype:generate |
3.2. 常用功能
Gradle 提供了许多常用功能，包括但不限于以下内容：
增加依赖：通过在构建脚本中添加依赖声明来引入外部库。例如使用 implementation 关键字添加编译时依赖，或者使用 testImplementation 添加测试时依赖。
dependencies {
implementation 'com.example:library:1.0.0'
testImplementation 'junit:junit:4.12'
}
剔除依赖：有时候你可能需要排除特定的传递性依赖。你可以使用 exclude 方法来剔除依赖项。
dependencies {
implementation('com.example:library:1.0.0') {
exclude group: 'org.unwanted', module: 'unwanted-module'
}
}
全局依赖版本管理：使用 dependencyManagement 插件进行全局依赖版本管理。这样一来，你就可以在单独的位置定义和管理依赖库的版本，而不需要在每个模块中都重复声明。
dependencyManagement {
imports {
mavenBom 'group:artifact:version'
}
}
增加插件：通过 plugins 块或者 apply plugin 语句来增加插件。Gradle 提供了很多内置的插件，同时也可以使用第三方插件。
plugins {
id 'java'
id 'application'
}
自定义任务：你可以创建自定义任务来执行项目特定的操作，比如清理临时文件、运行定制化的构建过程等等。
这些只是 Gradle 提供的众多功能之一。Gradle 还提供了许多其他强大的功能，比如多项目构建、增量构建、构建缓存、定制化构建逻辑等等。Gradle 的灵活性使得它成为一个广泛使用的构建工具，能够满足各种不同规模和类型的项目需求，具体的请自行探索。
3.4. 依赖版本冲突问题
3.4.1. 依赖传递性和版本冲突
1、依赖传递性
假设你的项目依赖于一个库，而这个库又依赖于其他库。你不必自己去找出所有这些依赖，你只需要加上你直接依赖的库，Gradle会隐式的把这些库间接依赖的库也加入到你的项目中。
2、传递性依赖中版本冲突：
由于传递性依赖的特点，两个不同版本的jar包会被依赖进来，这样就存在版本冲突的问题。
3.4.2. 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中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优胜。
3.4.3. 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'
3.4.4. Gradle 中解决冲突的办法-手动修改依赖：
手动排除依赖：
dependencies {
implementation(group: 'org.springframework', name: 'spring-jdbc', version: '5.1.3.RELEASE'){
exclude group:'org.springframework',module:'spring-beans'
}
}
后续可以自己手动配置你想要的版本的依赖。
修改默认配置策略，对所有jar不做冲突自动解决：
configurations.configureEach {//.all
resolutionStrategy{
failOnVersionConflict()
}
}
就会在构建时候抛出异常：
手动指定某个jar 的版本：
force:强制覆盖某个版本：
configurations.configureEach {
resolutionStrategy{
force 'org.springframework:spring-beans:5.3.12'
}
}
4. 新老版本 Gradle 区别
比如公共模块 common 中的依赖需要传递给其他模块，则需要使用 api：
