1. 前言
最近博主的许多朋友都陆陆续续入职了，发现他们公司有使用到Gradle作为系统的构建工具的，那既然公司需要，所以我们就要学习。故今天我们就来了解学习下Gradle这个构建工具的使用。提到项目自动化构建工具，大家首先想到的是maven，那接下来我们就聊一下Gradle与maven之间的一个差异。
首先，同样作为项目自动化构建工具maven，侧重于项目jar包的管理，而Gradle则侧重于项目的构建。
其次，在构建性能方面。Gradle的构建性能是要远高于maven的。尤其是针对大型多项目的构建。
我们这里还有其他几点学习Gradle的原因，比如spring家族框架的支持。如果目前我们想要学好spring家族框架的源码。比如说spring的源码，你会发现在GitHub上，它已经由maven转交给了Gradle进行管理。 
然后在技术雷达这个网站上，Maven已经被列入暂缓区了
2. 简介
Gradle 是一款先进的构建自动化工具，由 Google 专为 Java 应用开发而设计。
它基于 JVM，提供了一种灵活、可扩展的构建系统。Gradle 支持多种第三方仓库，如 Maven 和 JCenter，便于依赖管理。其最大的特点在于简化和优化了依赖项的处理，采用传递性依赖管理机制，避免了传统 XML 配置文件的复杂性。
取而代之的是，Gradle 使用 Groovy 或 Kotlin 等现代编程语言编写简洁的构建脚本，大幅提高了构建过程的灵活性和效率。
官网地址：Gradle Build Tool
3. 常见的项目构建工具
Ant（2000年推出）: Apache推出的基于Java的构建工具，通过build.xml文件管理项目。
优点：灵活、速度快（比Gradle和Maven快）。
缺点：没有强加编码约定和项目目录结构，需要编写复杂的XML文件，对开发人员有挑战。
Maven（2004年推出）: Apache组织推出的，使用pom.xml文件管理项目。
优点：遵循“约定大于配置”原则，使用统一的GAV坐标进行依赖管理，侧重于包管理。
缺点：项目构建过程较僵化，配置文件编写不够灵活，不方便自定义组件，构建速度慢于Gradle。
Gradle（2012年推出）: Google推出的基于Groovy语言的构建工具，集合了Ant和Maven的优点。
优点：结合了Ant的灵活性和Maven的“约定大于配置”原则，支持多种远程仓库和插件，侧重于大项目构建。
缺点：学习成本高、资料较少、脚本灵活但版本兼容性较差。
| 自动化构建工具对比 | Ant | Maven | Gradle |
| 构建性能 | 最高 | 最低 | 居中 |
| 仓库 | 开发者自己处理 | maven仓库 | 支持多种远程仓库 |
| 依赖管理 | ivy管理 | GAV坐标管理 | GNV坐标管理 |
| 插件支持 | 实现方便 | 实现较难 | 实现方便 |
| 遵循特定目录结构 | No | 遵循 | 同maven |
| 配置文件 | xml文件最为繁琐 | xml文件 | 代码脚本便于写业务逻辑 |
| 侧重点 | 小型项目构建 | 项目包管理 | 大型项目构建 |
| 目前地位 | 使用较少 | 目前主流 | 未来趋势(spring家族) |
无论哪种项目构建工具，都有自身的优势和劣势，所以选择一款最适合自己的就是最好的。
4. 安装
4.1. 安装说明
在SpringBoot 3.0.0 官方文档明确指出,目前 SpringBoot 的 Gradle 插件需要 gradle 7.x 版本及以上
其中 SpringBoot 与 Gradle 存在版本兼容问题，Gradle 与 Idea 也存在兼容问题，那么相应的 idea 版本也要升级,不能太老。
那我该如何查看我们本地安装的IDEA，它需要的是哪个版本的Gradle 呢？
这样我们就可以知道我们要安装哪个版本的Gradle 了。
还有就是Gradle 是依赖Java的，所以我们一定要先安装Java。
SpringBoot 具体参考文档: Spring Boot Gradle Plugin Reference Guide
4.2. 下载并解压
下载地址：Gradle | release (gradle.org)
下载完成后解压到本地
4.3. 配置环境变量
接下来我们配置环境变量，如图操作即可
我们新建环境变量，变量名为GRADLE_HOME，变量值为你Gradle文件解压的位置
接着，我们再双击Path，添加一个GRADLE_USER_HOME环境变量
GRALE_USER_HOME 相当于配置 Gradle 本地仓库位置和 Gradle Wrapper 缓存目录。
4.4. 检测是否安装成功
通过gradle -v或者 gradle --version检测是否安装成功
5. Gradle 项目目录结构
Gradle 项目默认目录结构和 Maven 项目的目录结构一致,都是基于约定大于配置【Convention Over Configuration】。
my-project/ |-- build.gradle (或 build.gradle.kts 如果使用 Kotlin DSL) |-- gradle.properties |-- gradlew (Gradle Wrapper 脚本) |-- gradlew.bat (Windows 下的 Gradle Wrapper 脚本) |-- settings.gradle (或 settings.gradle.kts 如果使用 Kotlin DSL) |-- src/ | |-- main/ | | |-- java/ (Java 源代码) | | |-- resources/ (资源文件，如 properties 文件) | | |-- webapp/ (对于 Web 应用) | | |-- WEB-INF/ | | |-- web.xml (对于传统的 WAR 包部署的 Web 应用) | |-- test/ | |-- java/ (Java 测试代码) | |-- resources/ (测试资源文件) |-- .gitignore (如果使用 Git 进行版本控制) |-- gradle/ | |-- wrapper/ | |-- gradle-wrapper.jar | |-- gradle-wrapper.properties
这个结构包括以下部分：
build.gradle (或 build.gradle.kts): 这是 Gradle 的构建脚本，定义了项目的构建逻辑。
gradle.properties: 用于存储 Gradle 构建时的属性，如 Gradle 版本或其他配置。
gradlew 和 gradlew.bat: 这是 Gradle Wrapper 的脚本，它允许你在不需要预先安装 Gradle 的情况下构建项目。
settings.gradle (或 settings.gradle.kts): 当项目包含多个子项目时，这个文件用于配置项目的层次结构。
src: 源代码和资源的主目录。
main: 主源代码和资源。
test: 测试源代码和资源。
.gitignore: Git 版本控制系统使用这个文件来忽略不必要的文件或目录。
gradle/wrapper: Gradle Wrapper 的目录，包含了执行 Gradle 构建所需的 JAR 文件和属性文件。 请注意，根据项目的不同，可能还会有其他目录和文件，如用于依赖管理的 lib 目录，用于文档的 docs 目录，或者用于构建输出的 build 目录等。此外，使用不同的插件和构建工具（如 Maven 或 Ant）可能会引入其他文件和目录。
Tips:
只有war工程才有webapp目录，对于普通的jar工程并没有webapp目录
gradlew与gradlew.bat执行的指定wrapper版本中的gradle指令,不是本地安装的gradle指令哦。
6. Gradle 创建第一个项目
借助于 spring 脚手架创建 gradle 第一个项目：start.spring.io/
如果图中没有你的有的Java版本，例如java8,也可以选择使用阿里云的镜像进行构建：start.aliyun.com
下载下来的代码压缩进行解压，然后用idea打开，查看生成的 gradle 项目目录结构如下所示:
6.1. Gradle 中的常用指令
需要注意的是： gradle 的指令要在含有 build.gradle 的目录执行。
| gradle命令 | 作用 |
| gradle clean | 清空build目录 |
| gradle classes | 编译业务代码和配置文件 |
| gradle test | 编译测试代码,生成测试报告 |
| gradle build | 构建项目 |
| gradle build -x test | 跳过测试构建构建 |
6.2. 修改 maven 下载源
Gradle 自带的 Maven 源地址是国外的，该 Maven 源在国内的访问速度是很慢的，除非使用了特别的手段。
一般情况下，建议使用国内的第三方开放的 Maven 源或企业内部自建 Maven 源。
6.2.1. 认识 init.d 文件夹
我们可以在 gradle 的 init.d 目录下创建以.gradle 结尾的文件，.gradle 文件可以实现在 build 开始之前执行，所以你可以在这个文件配置一些你想预先加载的操作。
6.2.2. 在 init.d 文件夹创建 init.gradle 文件
文件内容:
allprojects { repositories { mavenLocal() maven { name = "Alibaba" url = "https://maven.aliyun.com/repository/public" } maven { name = "Bstek" url = "https://nexus.bsdn.org/content/groups/public/" } mavenCentral() } } buildscript { repositories { maven { name = "Alibaba" url = "https://maven.aliyun.com/repository/public" } maven { name = "Bstek" url = "https://nexus.bsdn.org/content/groups/public/" } maven { name = "M2" url = "https://plugins.gradle.org/m2/" } } }
拓展1：启用 init.gradle 文件的方法有：
在命令行指定文件，例如：
gradle -I /path/to/some/init.gradle -q taskName
你可以多次输入此命令来指定多个 init 文件。
把 init.gradle 文件放到 USER_HOME/.gradle/ 目录下。
把以 .gradle 结尾的文件放到 USER_HOME/.gradle/init.d/ 目录下。
把以 .gradle 结尾的文件放到 GRADLE_HOME/init.d/ 目录下。 如果存在上面的4种方式的2种以上，Gradle 会按上面的1-4序号依次执行这些文件。如果给定目录下存在多个 init 脚本，会按拼音 a-z 顺序执行这些脚本。每个 init 脚本都存在一个对应的 Gradle 实例，你在这个文件中调用的所有方法和属性，都会委托给这个 Gradle 实例，每个 init 脚本都实现了 Script 接口。
拓展2：仓库地址说明
mavenLocal()：需要配置maven环境变量，指定使用 Maven 本地仓库。本地仓库在配置 Maven 时 settings.xml 文件指定的仓库位置，例如 E:/repository。Gradle 查找 jar 包顺序如下：
USER_HOME/.m2/settings.xml
M2_HOME/conf/settings.xml
USER_HOME/.m2/repository
maven{url地址}：指定 Maven 仓库；一般用私有仓库地址或其它的第三方库（比如阿里镜像仓库地址）。
mavenCentral()：这是 Maven 的中央仓库。无需配置，直接声明就可以使用。
jcenter()：JCenter 中央仓库。实际也是用的 Maven 搭建的，但相比 Maven 仓库更友好，通过 CDN 分发，并且支持 HTTPS 访问。在新版本中已经废弃了，替换为了 mavenCentral()。
总之，Gradle 可以通过指定仓库地址为本地 Maven 仓库地址和远程仓库地址相结合的方式，避免每次都会去远程仓库下载依赖库。这种方式也有一定的问题，如果本地 Maven 仓库有这个依赖，就会从直接加载本地依赖；如果本地仓库没有该依赖，那么还是会从远程下载。但是下载的 jar 不是存储在本地 Maven 仓库中，而是放在自己的缓存目录中，默认在 USER_HOME/.gradle/caches 目录。当然如果我们配置过 GRADLE_USER_HOME 环境变量，则会放在 GRADLE_USER_HOME/caches 目录。
拓展3：阿里云仓库地址请参考：阿里云 Maven 服务。
6.3. Wrapper 包装器
Gradle Wrapper 是对 Gradle 的一层封装，旨在解决不同项目可能需要不同版本的 Gradle 的问题。这在代码共享的场景中尤其有用，例如：
对方电脑未安装 Gradle：如果没有 Gradle Wrapper，接收方需要先安装相应版本的 Gradle 才能构建项目。
对方电脑安装的 Gradle 版本过旧：即使安装了 Gradle，版本不匹配也会导致构建失败。
这时候，我们就可以考虑使用 Gradle Wrapper 了。这也是官方建议使用 Gradle Wrapper 的原因。实际上有了 Gradle Wrapper 之后，我们本地是可以不配置 Gradle 的,下载 Gradle 项目后，使用 gradle 项目自带的 wrapper 操作也是可以的。
那如何使用 Gradle Wrapper 呢？
项目中的gradlew、gradlew.cmd脚本用的就是wrapper中规定的gradle版本。参见源码
使用 Gradle Wrapper 的方式与直接使用 Gradle 命令基本相同，只需将 gradle 命令替换为 gradlew（或 gradlew.bat 在 Windows 系统中）。
例如，如果原本使用 gradle build 来构建项目，使用 Gradle Wrapper 后，应使用 gradlew build。
GradleWrapper 的执行流程：
当首次执行 ./gradlew build 命令时，gradlew 脚本会读取 gradle-wrapper.properties 文件以获取配置信息。该文件指定了所需的 Gradle 版本以及下载和解压 Gradle 发行版的地址。具体步骤如下：
gradlew 脚本根据 gradle-wrapper.properties 文件中指定的版本信息，自动下载对应的 Gradle 发行版。
下载的 Gradle 发行版会被解压到 GRADLE_USER_HOME 目录下的 wrapper/dists 子目录中。如果未设置 GRADLE_USER_HOME，则默认使用用户主目录下的 .gradle 目录。
在执行构建过程中，Gradle 会创建本地缓存，这些缓存位于 GRADLE_USER_HOME 目录下的 caches 子目录中。这样，当再次使用相同版本的 Gradle 时，就无需重新下载，可以直接利用本地缓存。
之后，每次执行 ./gradlew 命令时，都会使用 gradle-wrapper.properties 文件中指定的 Gradle 版本来执行任务，确保了项目构建的一致性和可复现性。
如果遇到超时问题，我们可以把gradle-wrapper.properties中的超时时间参数改大一点。
gradle-wrapper.properties 文件解读:
| 字段名 | 说明 |
| distributionBase | 下载的Gradle压缩包解压后存储的主目录 |
| distributionPath | 相对于distributionBase的解压后的Gradle压缩包的路径 |
| zipStoreBase | 同distributionBase，只不过是存放zip压缩包的 |
| zipStorePath | 同distributionPath，只不过是存放zip压缩包的 |
| distributionUrl | Gradle发行版压缩包的下载地址 |
使用 Gradle Wrapper (gradlew) 的场景：
当您下载或克隆一个项目时，通常应该使用该项目提供的 Gradle Wrapper (gradlew 或 gradlew.bat)。这是因为 Wrapper 确保了项目使用正确的 Gradle 版本来构建，这样可以避免由于 Gradle 版本不兼容导致的构建失败。
当您要操作之前自己写的不同版本的 Gradle 项目时，也应该使用相应项目的 Gradle Wrapper，以确保每个项目都能以其所需的 Gradle 版本运行。
使用本地 Gradle 的场景：
当您新建一个项目时，如果您没有特别的版本要求，可以使用本地安装的 Gradle。在这种情况下，您可以直接使用 gradle 命令来执行构建任务。但是，建议为新的项目也生成一个 Gradle Wrapper，这样项目就可以独立于开发者的本地 Gradle 环境了。
如果您需要在项目中使用特定版本的 Gradle，或者想要确保项目在任何环境下都能以相同的方式构建，那么即使是新项目，也应该使用 Gradle Wrapper。 总的来说，除非有特殊原因需要使用特定版本的 Gradle，否则使用 Gradle Wrapper 是一个更好的选择，因为它提供了构建的一致性和便利性。
7. 总结
本文简单的介绍了Gradle的安装和下载，以及如何使用Gradle创建项目，如果需要学习更多Gradle相关的知识，可以阅读Gradle官方文档Gradle | 开发者文档。
