一、Gradle
Gradle 与 Maven 的区别可以看这篇 文章。
日常作为简单的依赖管理使用哪个都是没有问题的。有句话说的好:高端玩家选择自定义设置,普通玩家选择默认配置 😄 高级功能不一定使用。
不过另一方面,Gradle 社区更新、更换 API 很勤快,也许上个版本还在用的 API,等更新版本后就幸运的看到了中国红!所以大家对 Maven 的版本要求一点儿也不严格,但是对于 Gradle,emmmm,这个得看你们的依赖脚本用了什么 API。
本文示例全部使用 kts
的写法(Gradle Version >= 7),也就是 kotlin 式的语法,体验比 Groovy 棒多啦!推荐可以看一下 B 站霍老师的的视频:
二、配置
Gradle 的配置分为两种,一种是本地安装的方式,就和本地安装的 Maven 一样;另一种则是直接配置一个环境变量。这 两种方式二选一 就好。
gradle 默认的 url 分发地址,大概在 2023 年 9 月份开始,官网的下载速度就不行了,之前飞快,现在只能找找国内镜像。
第一种:设置 GRADLE_USER_HOME
环境变量,该变量不需要扔到 Path 里,只需要配置一个存储空间较大的路径,后面在使用 IDE 的时候,如果自动下载,那么所有版本的 gradle 安装包、依赖都会下载到此目录。结构如下(使用后就有了):
1 | ├── caches # 依赖包 |
第二种:本地安装😉在本地安装的目录中添加以下文件。
1 | allprojects { |
脚本路径
若本地安装了 Gradle,上面的脚本就放在本地安装的目录中;若本地未安装,放在配置的环境变量的目录中;如果前面两项都不满足,那么放在默认的路径:~/.gradle 。
若本地安装且配置了环境变量,命令行才可以使用 gradle;未安装只能在项目路径下使用 ./gradlew 命令(wrapper 会自动调用守护进程)。
关于环境变量请参考 Gradle 官网。
GRADLE_HOME
自己本机安装的 Gradle 目录;GRADLE_USER_HOME
:自定义下载依赖的存放的路径,包括wrapper/gradle/
下定义的各种版本的 Gradle 及其下载的依赖。在GRADLE_USER_HOME
变量缺失的时候,默认的位置为~/.gradle/
。
Gradle 是如何查找并使用本地的配置呢?
1 | # Gradle 查找下载配置的顺序 * 代表可以为任意名称 |
三、几个重要文件
单模块很简单,本文就不演示了。这里使用多模块项目作为一个小示例:
1 | |-- Project |
1. settings.gradle.kts
1 | // 项目根文件夹名称 |
2. build.gradle.kts
该文件是我们最常见、常改的文件。
1 | // 项目使用插件 |
3. gradle.properties
该文件可以声明 gradle 使用的环境变量,进而覆盖 gradle 的默认配置。也可以在这里定义、维护版本号,总之这里的内容可以在被上面两个文件引用。
1 | # 启用守护进程 |
四、Gradle scope
在Gradle中,有几种不同的依赖范围,它们定义了依赖在不同阶段的行为和可见性。以下是一些常见的依赖范围:
-
api:
- 在新的Android插件和一些非Android项目中,推荐使用
api
替代compile
。 api
范围的依赖在编译和运行时都是可用的,并且会被传递到依赖此模块的其他模块。- 这意味着,当你在某个模块中使用
api
来声明一个依赖时,这个依赖会同时被编译和打包到该模块的输出,并且任何依赖于这个模块的其他模块也将能够访问到这个依赖。
- 在新的Android插件和一些非Android项目中,推荐使用
-
implementation:
implementation
范围的依赖在编译和运行时对当前模块是可用的,但在编译依赖此模块的其他模块时不可见。- 这意味着,如果你在一个模块中使用
implementation
依赖了一个库,那么其他依赖这个模块的模块需要自己再次声明对这个库的依赖。
-
runtimeOnly(或
runtime
):runtimeOnly
范围的依赖只在运行时是必需的,编译时不需要。- 这种依赖通常用于那些只需要在运行时加载的库,如JDBC驱动、日志框架的配置文件等。
-
testImplementation:
testImplementation
范围的依赖只在编译和运行测试代码时需要,不会影响主代码的编译和运行。- 这种依赖通常用于测试框架和相关的库。
-
testRuntimeOnly:
testRuntimeOnly
范围的依赖只在运行测试时需要,编译测试代码时不需要。- 这种依赖通常用于那些只在测试环境中使用的资源或库。
只有使用
java-library
才可以使用 api,java-library
插件是 java 插件的升级,它支持 java 插件的所有功能,并引入了额外的新功能。
五、Version Catalog
Gradle 7.x 引入了 version catalog 功能预览,gradle 8 默认启用(读取项目目录下的 gradle/libs.versions.toml
),对于 Gradle 多模块需要依赖共享的项目非常好用。version-catalog 方式引入的依赖也是惰性的,即在文件中声明的依赖如果没有项目引入,则不会进行下载。
个人不是很喜欢 extra 和 buildSrc 的方式,当然,如果使用 kts
可以在文件里直接 val xxxVersion = "version"
更香。
在项目根目录的 gradle/
目录中创建 libs.versions.toml
文件管理所有依赖,子项目中按需引入。该文件分为以下几个部分(里面的内容只是例子):
1 | [versions] |
子模块使用时非常简单:
1 | // 使用 libs.versions.toml 定义的插件 |
libs.versions.toml
是 Gradle 默认查找并读取的文件名称,也可以使用其它名称(譬如开发和生产使用不同类型、不同版本的依赖项,可能会定义多个文件),不过需要在settings.gradle.kts
中做一些配置,让 Gradle 可以读取,配置方式自行查阅 官方文档。- 版本定义上面使用了
version.ref
的方式,也可以使用version
直接写版本字符串,例如spring-boot = { module = "org.springframework.boot:spring-boot", version = "3.3.3" }
。- 在
libs.versions.toml
中定义名称使用-
分割(spring-boot),但在使用时需要使用.
分割(libs.spring.boot)。
六、附:CLI 命令
1 | # 查看帮助 |