Gradle依赖管理-基于KotlinDSL
Gradle依赖管理(基于Kotlin DSL)
Gradle构建工具是一个快速、可靠和适应性强的开源构建自动化工具,具有优雅和可扩展的声明性构建语言,Gradle包含许多优势:
- Gradle是JVM平台最受欢迎的构建系统,也是Android和Kotlin多平台项目的默认选择,它拥有丰富的社区插件生态系统。
- Gradle可以使用其内置函数、第三方插件或自定义构建逻辑自动执行各种软件构建场景。
- Gradle提供了一种高级、声明式和富有表现力的构建语言,使阅读和编写构建逻辑变得很轻松。
- Gradle快速、可扩展,可以构建任意规模和复杂度的项目。
- Gradle产生可靠的结果,同时受益于增量构建、构建缓存和并行执行等优化。
Gradle支持Android、Java、Kotlin Multiplatform、Groovy、Scala、Javascript和C/C++等热门语言的构建工作:
Hello Gradle
首先,我们来学习Gradle的安装和初始化。
安装Gradle环境
在使用Gradle之前,我们先来看看如何安装,这里演示Ubuntu环境下如何进行安装,其他平台请参考官方文档:https://docs.gradle.org/current/userguide/installation.html#installation
在开始安装之前,首先确保您已经安装好Java环境(使用java --version
命令进行查看)版本不能低于Java 8,本教程使用的是Java 17版本:
确认无误后,我们进入到Gradle官网
这里我们选择直接下载已经编译好的二进制文件:
本教程教学采用的是8.8版本,如果各位小伙伴在学习时官方已经推出了新的版本,请务必选择跟教程相同的版本,因为Gradle的版本兼容性很差,不同版本出现特性变化的情况很常见,容易出现不兼容的情况。
下载完成后解压,然后将解压得到的目录拖到你想要安装的位置,本教程就放到/home/liaojie1314/env/gradle
目录下,然后添加环境变量:
1 | vim ~/.bashrc |
添加完成后,我们打开一个新的命令窗口,输入gradle -v
命令查看是否配置生效:
初始化Gradle项目
安装完成Gradle之后,我们就可以开始正式进行学习了,首先我们还是来尝试创建一个Gradle项目。
我们在当前目录打开CMD窗口,并执行以下命令:
1 | gradle init |
出现以下内容,让我们选择当前项目的类型,这里我们选择Application
应用类型,默认就是1: Application
:
1 | Select type of build to generate: |
接着是选择我们程序使用的语言类型,本教程统一使用Java语言讲解,选择Java
,默认就是1: Java
:
1 | Select implementation language: |
采用的Java版本,因为这里我们安装的是Java17,所以直接输入17即可,还有是否选择使用新特性直接no
就好了:
1 | Enter target Java version (min: 7, default: 21): 17 |
当前项目的名称,默认就是当前目录名字,这个自己根据情况选择吧,我这里输入gradle-kotlin
:
1 | Project name (default: gradle-kotlin): |
选择项目的结构,默认单应用就行:
1 | Select application structure: |
接着是编写Gradle脚本采用的语言,目前Gradle支持Kotlin和Groovy两种,且目前官方推荐的是Kotlin语言,所以这里默认就行:
1 | Select build script DSL: |
Gradle还需要配置一个测试使用的框架,这里我们选择默认的就行:
1 | Select test framework: |
接着是当前项目的名称以及包名,默认就是当前目录名字,这个自己根据情况选择吧:
1 | Project name (default: Test): |
最后是采用的Java版本,因为这里我们安装的是Java17,所以直接输入17即可,还有是否选择使用新特性直接no
就好了:
1 | Enter target version of Java (min. 7) (default: 17): 17 |
接着我们可以看到项目成功完成了初始化操作:
可以发现gradle给我们生成了许多文件:
不同版本的Gradle对我们使用的IDEA版本同样存在兼容性问题,这里推荐使用IntelliJ IDEA 2024.x
或更高版本,旧版本的IDEA可能会不支持当前的Gradle 8.8版本。
我们可以直接在IDEA中打开这个项目,打开后正常情况下会自动开始初始化,初始化过程中会下载很多东西,包括Gradle当前版本本身,以及它所需要的所有依赖包以及Kotlin相关库。
不对啊,我们本地不是已经安装了Gradle吗,怎么初始化项目的时候又要下载一次呢?这是因为Gradle Wrapper的作用,由于Gradle的跨版本兼容性很差,因此它指定了当前项目中使用的Gradle版本,使得不同的开发人员或CI/CD系统都能使用相同的Gradle版本来构建项目,从而提高项目的一致性和可移植性。Gradle Wrapper的另一个好处是,它可以自动下载和使用正确版本的Gradle,无需手动安装或配置Gradle,使得项目的维护和协作更加方便,后续别人拿到我们这个项目的时候,不需要自己在系统中部署Gradle环境。
这个过程中可能会很卡,因为服务器在国外(建议挂梯)直到出现BUILD SUCCESSFUL
之后,表示初始化完成:
我们来依次介绍一下这些内容分别代表什么以及有什么作用:
.gradle
:Gradle自动生成的项目缓存目录。app
:存放整个项目的源代码、测试等,这里面就是我们写代码的地方了。build.gradle.kts
:项目的gradle构建脚本。src
:存放源代码和测试代码。main
:编写所有项目核心代码。test
:编写项目测试代码。
gradle
:包含JAR文件和Gradle Wrapper的配置。gradlew
:适用于macOS和Linux的使用Gradle Wrapper执行构建的脚本(这里的版本就是GradleWrapper指定的版本)gradlew.bat
:适用于Windows的使用Gradle Wrapper执行构建的脚本。settings.gradle.kts
:定义子项目列表的项目配置文件,也是最关键的设置文件。
除了以上文件以外的其他文件,一般都是一些额外的Git文件,例如.gitignore
,不属于Gradle的范畴,无视掉就可以了。
Gradle项目在生成时默认为我们创建了一个测试的主类:
1 | /* |
我们可以在IDEA中尝试直接运行:
这样,咱们的第一个Gradle项目就成功创建并运行了。
当然你也可以使用idea创建gradle项目。
IDEA创建Gradle项目
项目配置:
下面内容讲解基于IDEA创建的项目,与使用gradle init创建的项目文件略有不同。
Gradle常用命令
我们在一开始就说了,Gradle最主要的目的就是为了构建大型项目,其中构建项目的常用命令非常关键,我们就来学习一下。
首先我们可以查看一下所有Gradle支持的任务,这里我们使用GradleWapper提供的gradlew
进行操作,使用方式其实和gradle
命令是一样的,只是这里用的是生成的(注意Windows平台下需要使用gradlew.bat来运行)
1 | ./gradlew task |
其中包含了大量的命令操作:
1 | > Task :tasks |
比如第一个run
命令就可以将当前项目以JVM应用程序的形式运行:
这个命令会自动编译并运行我们的项目,我们也可以手动执行其中的每一步,现在就来尝试一下吧,首先先执行一次清理命令,将整个项目目录进行一次清理,主要清理掉的就是构建出来的文件:
1 | ./gradlew clean |
我们在编写好一个Java项目之后,第一步就是编译成class文件,然后才能开始运行,所以,我们可以使用以下命令来编译代码:
1 | ./gradlew classes |
执行完成之后,如果出现BUILD SUCCESSFUL
表示编译成功,此时在app目录下会生成一个新的build目录,此目录中存放的就是编译之后的相关文件了,其中classes目录存放的就是所有编译之后的class文件:
有些时候我们的项目可能需要在编译之后运行一些测试用例,来快速查看是否存在一些问题,这在开发过程中非常常见,我们可以看到Gradle默认情况下为我们生成了一个简易的测试用例:
1 | /* |
我们可以将App类中的getGreeting方法的返回值设置为null试试看:
1 | public class App { |
使用以下命令来执行测试:
1 | ./gradlew test |
可以看到测试失败了,并且Gradle还自动为我们生成了一个错误报告,其中明确指出了我们出现错误的测试用例:
我们也可以快速执行一个完整的编译+测试流程来构建整个项目,并得到打包好的jar等文件,使用以下命令来完成:
1 | ./gradlew build |
如果某些时候我们不想执行测试,只想构建整个项目,也可以添加参数跳过:
1 | ./gradlew build -x test |
只不过这样去敲命令实在是太累了,在IDEA中已经自动帮助我们继承了Gradle插件,我们可以直接展开右侧工具栏,双击就能使用Gradle命令了,非常方便:
项目配置
前面我们介绍了Gradle项目的搭建与使用,我们先来看一下整个Gradle项目构建的流程:
大概清楚构建流程后,我们接着就来了解一下Gradle项目是如何进行配置的。
配置文件介绍
设置文件settings.gradle
是整个Gradle项目的入口点:
设置文件用于定义所有的子项目,并让它们参与到构建中,Gradle支持单项目和多项目的构建:
- 对于单个项目构建,设置文件是可选的。
- 对于多项目构建,设置文件必须存在,并在其中定义所有子项目。
设置文件可以使用Groovy语言(名称为settings.gradle
)或是Kotlin语言(名称为settings.gradle.kts
)编写,本教程一律采用Kotlin语言进行讲解,设置文件通常位于项目的根目录中:
一个标准的Gradle设置文件按照以下样式进行编写,这里使用Kotlin语言介绍:
1 | rootProject.name = "root-project" //rootProject对象代表当前这个项目,其name属性就是当前项目的名称 |
接着我们来看针对于单个项目的构建文件,其中gradle.build
文件就是对应的构建配置,这里我们使用的是Kotlin语言,因此项目中会存在一个gradle.build.kts
文件:
1 | plugins { |
可以看到,在这个配置文件中存在大量的Lambda语句,这也使得整个配置文件写起来更加简介美观,所以说虽然Gradle依赖于JVM平台,但是仅支持Kotlin和Groovy,它们相比Java在语法上存在更大的优势,更适合编写这种类似脚本一样的配置文件。
我们首先来看最顶上的plugins函数,后面的Lambda中编写了当前项目需要使用到的插件:
1 | plugins { |
使用id()
函数指定需要使用的插件,这里使用的是java
插件,java
插件将Java编译以及测试和捆绑功能添加到项目中,为建任何类型的 Java 项目提供支持。
当然,除了java插件之外,我们如果需要构建其他类型的项目,也可以使用多种多样的插件:
1 | plugins { |
1 | plugins { |
1 | plugins { |
有关插件相关的内容,我们会在后面的部分深入为大家介绍,不同的插件会为Gradle添加不同的任务。
这里的group和version分别设置了当前项目所属的组名称和版本:
1 | group = "blog.yuanyuan" |
接着是所有依赖的仓库配置,默认使用的是Maven中心仓库:
1 | repositories { |
接着是所有的依赖列表,这里默认为我们导入了JUnit相关依赖用于测试:
1 | dependencies { |
最后是任务相关配置,这里对test
任务进行了相关配置:
1 | tasks.test { |
编写设置文件
我们前面介绍了Gradle构建的大致流程和配置文件各个部分,而设置文件settings.gradle.kts
则是整个构建的入口点,在Gradle构建生命周期的早期,初始化阶段会在项目根目录中找到设置文件。
当找到设置文件settings.gradle(.kts)
时,Gradle会实例化一个Settings
对象,我们可以通过此对象来声明要包含在构建中的所有项目,包括我们项目名称的声明也是通过它来完成:
1 | settings.rootProject.name = "gradle-kotlin" |
我们也可以省略掉settings直接使用其提供的属性:
1 | rootProject.name = "gradle-kotlin" |
其中,Settings对象包含以下常用属性:
姓名 | 描述 |
---|---|
buildCache | 项目构建所用缓存配置。 |
plugins | 用于设置的插件。 |
rootDir | 项目构建的根目录,根目录是整个项目目录最外层。 |
rootProject | 构建的根项目。 |
settings | 返回设置对象。 |
Settings对象也包含以下方法可供调用:
姓名 | 描述 |
---|---|
include() | 将指定名称的项目添加到构建列表中。 |
includeBuild() | 添加指定路径上的其他Gradle项目到构建列表中。 |
我们在编写配置文件时,本质上是对Gradle API的一系列方法调用,结合Groovy或Kotlin的{...}
语法(在Groovy中称作闭包,Kotlin中称为Lambda)能够轻松编写非常简洁的配置,比如配置插件:
1 | rootProject.name = "gradle-kotlin" |
在配置文件中定义的语句,Gradle会一行一行地向下执行,就像一个脚本那样。实际上,我们编写的配置文件在执行Gradle构建时会编译为对应的class文件加载执行,这些文件存放在Gradle的缓存目录中。
因此,我们直接在Gradle配置中编写的自定义语句也可以执行:
这里我们执行了自定义的打印语句,包括可以通过rootProject
对象拿到当前的项目文件File对象等。
在Gradle中,和Maven一样也分为插件和依赖,我们可以在settings.gradle.kt
中可以为所有的项目进行统一配置,比如要修改获取插件的仓库位置:
1 | pluginManagement { //使用pluginManagement函数配置插件仓库列表 |
我们也可以修改为国内的阿里云镜像:
1 | pluginManagement { |
同样的,对于所有的依赖,也可以直接配置为国内的阿里云镜像仓库:
1 | dependencyResolutionManagement { //依赖解析管理中可以配置全局依赖仓库 |
不过,除了在settings.gradle.kts
中配置三方仓库之外,我们更推荐在之后学习的build.gradle.kts
中对仓库进行配置。
与Maven一样,Gradle插件可以帮助我们在构建过程中实现各种各样的高级功能,它是用于增加和扩展任务(tasks)或构建逻辑的一种特殊类型的模块,在settings.gradle.kts
中可以配置插件,只不通常被用于需要对多个项目进行操作的插件,或者需要在构建开始之前进行一些配置的情况:
1 | plugins { //使用id明确插件名称,使用version中缀函数明确插件版本 |
一般很少见有项目在这里配置插件。
对于多个子项目的大型项目而言,我们还需要在这里添加所有的子项目:
1 | include("app") |
有关多项目的详细介绍,我们会放在下一个章节,本章节主要以单项目为主。
除了以上提到的内容,Settings
对象上还有更多属性和方法,您可以使用它们来配置构建。不过,虽然许多Gradle脚本通常以简短的Groovy或Kotlin语法编写,但设置脚本中的每个操作都是在Settings
对象上调用方法:
1 | include("app") |
编写构建脚本
前面我们介绍了设置文件的编写,它是我们整个项目的构建起点,包含了所有基本内容的配置。
我们接着来看针对于我们每一个项目的构建脚本build.gradle.kts
文件:
对于设置文件中包含的每个项目,Gradle都会为其创建一个Project
实例对象,我们可以直接在build.gradle.kts
中使用,跟之前一样,可以省略:
1 | group = "blog.yuanyuan" |
1 | project.group = "blog.yuanyuan" //本质上就是project的属性 |
在此对象中,包含以下常见属性:
姓名 | 类型 | 描述 |
---|---|---|
name | String | 项目目录的名称。 |
path | String | 该项目的完全限定名称。 |
description | String | 该项目的描述。 |
dependencies | DependencyHandler | 配置项目的依赖列表。 |
repositories | RepositoryHandler | 配置项目的依赖仓库。 |
layout | ProjectLayout | 通过此对象来访问项目中的关键位置。 |
group | Object | 项目的组。 |
version | Object | 项目的版本。 |
我们依次来看每个部分是如何进行编写的。
首先是整个项目所采用的插件,我们可以像下面这样编写:
1 | plugins { |
其中,插件application
是由官方内置的插件,可以直接使用id()
函数来选择,而上面的org.jetbrains.kotlin.jvm
插件没有被官方内置,需要我们手动使用version
中缀函数指定其版本,这样Gradle才能在仓库中正确找到它。
一般情况下,我们普通的Java项目可以直接使用java
插件,它能够直接完成编译和打包Java代码:
1 | plugins { |
我们也可以对这个插件进行一些配置,比如我们要生成目标的Java版本等:
1 | configure<JavaPluginExtension> { |
如果我们需要将项目打包为一个可执行的文件,也可以使用application
插件,它包含java
插件的全部功能,同样支持编译和打包Java代码,并且支持生成可执行的应用程序:
1 | plugins { |
配置完成后,我们直接执行build
构建项目,生成以下文件:
可以看到这里生成的压缩包的形式,我们可以直接解压,得到一系列文件。可以看到,在bin目录中已经生成了用于运行我们Java项目的脚本(Mac/Linux是项目名称的脚本,Windows是bat脚本)然后在lib目录中是已经帮我们打包好的项目jar文件,如果我们项目中还存在其他的依赖,也会包含在这个lib中。我们可以直接运行:
这跟我们前面学习的Maven其实非常相似,同样可以通过插件实现打包,只不过这里是采用编程的形式配置,而Maven统一采用XML形式进行配置。
接着我们来看如何配置项目中的依赖项,首先是对于依赖仓库的选择,默认情况下生成的代码选择的是Maven中心仓库:
1 | repositories { |
我们可以自己定义,比如只使用本地仓库中的包:
1 | repositories { |
我们可以通过maven
函数来直接指定第三方仓库:
1 | repositories { |
配置好仓库地址后,我们就可以开始添加需要的依赖了,在dependencies
中进行编写,默认情况下添加了一些测试相关的依赖:
1 | dependencies { |
这里我们可以使用两种不同的函数导入依赖:
implementation
导入依赖,用于编译和运行生产代码。testImplementation
导入依赖,用于编译和运行测试代码。
其中填写的字符串就是我们依赖的组、名称以及其对应的版本号:
org.junit:junit-bom:5.10.0
对应的组为org.junit
,依赖名称为:junit-bom
,版本号为:5.10.0
我们可以尝试一下添加自己需要的依赖,比如这里我们添加一个Spring框架的核心依赖,首先我们可以在这里找到需要的包:https://central.sonatype.com,找到后选择:
然后直接粘贴到依赖列表里面即可:
1 | //使用implementation来添加依赖 |
更新后,就可以直接使用了:
1 |
|
使用起来跟Maven其实差别不是很大。
当然,除了像这样写在一起之外,我们也可以分开进行编写,把组、名称和版本填写为三个参数:
1 | implementation("org.springframework", "spring-context", "6.1.10") |
我们有些时候希望一直使用最新版本的依赖,也可以直接将版本设置为+
来始终使用最新版本:
1 | implementation("org.springframework:spring-context:+") |
深入依赖配置
上一部分我们介绍了如何导入依赖,我们接着来看导入依赖之后的更多操作。
除了通过直接编写Maven坐标的形式来引入仓库中的依赖之外,我们也可以直接将一个本地的Jar包引入到项目中,这里我们在项目根目录下新建一个lib
目录,用于存放我们需要引用的Jar包。
接着我们在依赖中编写引入的语句:
1 | dependencies { |
如果我们一个目录下的jar包太多,需要全部导入,像上面这样一个一个写太累了,我们可以直接使用fileTree方法来统一获取:
1 | implementation(fileTree("lib")) //直接引入lib下全部jar包 |
效果和上面一个一个导入一样。
我们接着来看依赖的排除,在之前Maven的学习中我们知道,一个依赖的内部可能又会存在多个依赖,在使用一些依赖时,我们可能希望排除其中某些不需要的依赖或是与其他依赖冲突的依赖,我们可以对依赖进行排除操作:
1 | implementation("org.springframework:spring-context:6.1.10") { |
这里我们在引入spring-context
之后,不需要其中的AOP模块,因此我们可以直接使用exclude函数将其排除,此时AOP模块就不存在于外部库中了。
我们再来看下面这种情况:
1 | implementation("org.springframework:spring-context:6.1.10") |
此时我们的项目中不仅依靠spring-context
引入了spring-aop
的6.1.10版本,也手动引入了spring-aop
的6.1.1版本,此时Gradle会优先使用更新的版本作为依赖,所以这里实际引入使用的也是6.1.10版本。
如果我们执意要使用旧版本的依赖,可以通过上面的方式进行依赖的排除,或是给版本号添加感叹号表示强制使用:
1 | implementation("org.springframework:spring-context:6.1.10") { |
1 | implementation("org.springframework:spring-context:6.1.10") |
最后我们来列举一下DependencyHandlerScope里面包含的方法:
implementation
: 用于添加项目的依赖项,这是最常用的方法。api
: 与implementation
类似,但它会暴露依赖项给项目的所有模块(多项目配置中讲解)compileOnly
: 用于指定编译时依赖,但不会在运行时包含在最终构建结果中。testImplementation
: 用于添加测试时需要的依赖项。androidTestImplementation
: 用于添加Android测试时需要的依赖项。kapt
: 用于添加 Kotlin 注解处理器依赖项。annotationProcessor
: 用于添加 Java 注解处理器依赖项。runtimeOnly
:仅在运行时使用,不用于编译
相信各位小伙伴对于implementation
已经非常熟悉了,它其实是Java插件提供的方法,我们可以使用它来引入依赖,并且在打包之后也会附带我们引入的依赖:
我们来看看其他的导入方式,首先是compileOnly
,它表示导入的依赖仅在编译时可用,编译完成后不会将依赖一起打包:
1 | compileOnly("org.springframework:spring-context:6.1.10") |
接着是runtimeOnly
,它表示导入的依赖仅在运行时可用,比如MySQL驱动这类我们不需要在项目中直接使用,但是在项目运行时又需要用到的依赖就非常适合:
1 | runtimeOnly("org.springframework:spring-context:6.1.10") |
此时,由于此依赖仅存在于运行时,项目中是无法使用的:
但是我们去掉这些不可用的代码,在编译之后,这些依赖却会被打包在一起。
自定义任务
Gradle可以在项目上完成的工作由一个或多个任务定义,任务代表构建执行的某些独立工作单元,比如编译一些类,创建jar包,生成Javadoc文档,或将一些内容发布到代码仓库,这些任务通常由插件提供,我们在项目中引入插件后就可以直接执行对应的任务了,在不引入任何插件的情况下,只会包含一些内置的默认任务:
在引入java
插件后,就出现了各种Java相关的任务,比如编译、构建、打包jar包等:
可以看到,这些任务都是由插件为我们提供的,因此,大部分情况下我们引入插件之后就可以直接执行相关的任务了。我们在执行某一个大任务的时候,就会执行一系列的任务,比如build
命令,它不仅完成构建,还将所有的任务依赖关系进行完整的建立,可以看到:
在整个build任务执行的过程中,依次按顺序执行了各种各样的任务:
- compileJava:编译所有Java源代码文件。
- processResources:处理所有资源文件,由于这个项目没有资源文件,提示 NO-SOURCE
- …
通过这一系列小任务,就完成了编译、构建、打包等一系列操作,只需要执行:./gradlew build
即可。
当然,如果各位小伙伴觉得插件提供的任务不太够,需要自定义添加,我们也可以在build.gradle.kts
中编写自定义任务:
注册任务需要使用register
或create
函数来完成,一个最简单的任务可以像下面这样编写:
1 | tasks.register("hello") { //第一个参数为任务名称,第二个参数使用Lambda编写任务具体操作 |
可以看到,刷新之后任务列表就出现了我们自定义的任务,执行之后也是我们自定义的内容:
我们也可以通过指令的形式直接运行:
在执行命令时,我们还可以添加额外的项目参数,在脚本中可以直接获取:
1 | tasks.register("hello") { |
我们还可以配置此任务所属的组别,以及其它描述信息:
我们还可以将一个任务作为gradle
执行的默认任务,也就是说直接执行gradle命令就可以运行我们的任务了:
1 | defaultTasks("hello") |
一个任务还可以依赖于其他任务,比如我们的自定义任务在执行之前需要先完成源代码的编译操作:
1 | tasks.register("hello") { |
在执行时,会先完成前置任务之后再执行当前任务:
我们也可以让已经存在的任务来依赖我们的任务或是直接为其添加额外的操作:
1 | tasks.named("build") { //根据名称进行查找 |
这样,我们就为任务build
添加了前置任务到前置任务列表中:
在Gradle中,实际上所有的任务都是Task的子类,除了向上面这样直接编写Task类型,包括我们在前面使用的register
方法,默认也是在Lambda中为我们提供一个Task类型的对象:
1 |
|
我们也可以自行创建Task的子类,来编写自定义的任务类型:
1 | // 继承 DefaultTask 类来创建一个自定义的 HelloTask 类,注意这个类必须要可继承,要么open要么直接抽象类 |
通过这种方式也可以实现任务的自定义:
除了通过插件或是我们自定义的形式编写任务之外,Gradle也为我们提供了一些内置的任务类型,这些任务通常是一些经常会用到的操作,我们可以来使用一下,比如复制任务:
1 | tasks.register<Copy>("hello") { //这里使用Copy类型 |
执行我们自定义的hello任务,就可以完成构建 + 拷贝了。
除了这里演示才Copy操作,开发人员还可以利用许多任务类型,包括GroovyDoc
、Zip
、Jar
、JacocoReport
、Sign
或Delete
等。
生命周期钩子
有些时候我们希望在Gradle的整个生命周期中的不同时段执行一些操作,我们可以使用官方提供的生命周期钩子函数。
大多已经弃用,官方推荐使用配置缓存API。
详情请参阅配置缓存
- 构建初始阶段
gradle.settingsEvaluated()
完成项目的配置阶段之后调用(只能定义在 setting.gradle 或 init.gradle 脚本中)gradle.projectsLoaded()
所有项目加载之后调用(只能定义在 setting.gradle 或 init.gradle 脚本中)
- 配置阶段
gradle.beforeProject()
每个项目完成配置之前调用(只能定义在 setting.gradle 或 init.gradle 脚本中)gradle.afterProject()
每个项目完成配置之后调用gradle.projectEvaluated()
所有项目全部完成配置之后调用gradle.afterEvaluate()
整个配置阶段完成后调用gradle.taskGraph.whenReady
全部任务图已经构建完成可以就绪后调用
- 执行阶段
gradle.taskGraph.beforeTask
执行每一个任务之前调用gradle.taskGraph.afterTask
每一个任务执行完成之后调用gradle.buildFinished
整个构建全部结束后调用
这里我们可以尝试编写一个钩子函数试试看:
1 | gradle.settingsEvaluated { |
这样,我们就可以在不同的阶段执行自定义的内容了。比如,我们可以利用这种特性来统计某一个阶段或是任务耗费的时间:
1 | var time: Long = 0 |
得到的结果就会自动计算每个任务的执行时间了:
项目发布
我们也可以将自己的的Gradle项目发布到的Maven仓库中,这里我们以发布到本地仓库为例:
1 | plugins { |
接着我们来配置发布相关的内容:
1 | publishing { |
接着我们执行publish
任务即可发布项目到本地仓库了,此时在.m2
目录中已经存在我们发布的项目了。
创建SpringBoot项目
通过IDEA或是前往SpringBoot官网就可以自动为我们创建一个基于Gradle的SpringBoot项目:https://start.spring.io/
这里使用IDEA创建,项目配置如下:
这里自动生成了项目的build.gradle.kts
文件:
1 | plugins { //首先是插件配置 |
JVM语言混合编程
打开之前学习gradle的项目,对于某些需要使用多种JVM语言进行编程的项目,我们可以同时配置多种插件,这里我们以Java与Kotlin混合编程为例进行讲解:
1 | plugins { //同时配置Java和Kotlin/JVM插件 |
编写好插件后,我们直接刷新项目,接着就可以在src下的main和test目录中同时创建两个源代码目录:
- java:存放Java源代码文件
- kotlin:存放Kotlin源代码文件
在main文件夹右键新增文件夹:
此时就可以在kotlin目录下编写Kotlin相关的源代码了:
1 | //位置:src/main/kotlin/blog/yuanyuan/Person.kt |
1 | //位置:src/main/java/blog/yuanyuan/App.java |
编写好之后,点击main方法旁边的运行按钮,可以看到一起编译了Java和Kotlin源代码,并成功运行:
如果要打包为可执行的应用,也可以直接使用application
插件:
1 | plugins { |
build打包之后,已经自动将Kotlin标准库依赖集成了,也可以直接使用:
这样,我们就可以愉快地进行混合编程了。
多项目配置
前面我们介绍的是单个项目的布局,现在我们接着来看多个项目的布局。
通常对于一些大型的分布式项目来说,我们会在一个项目中包含多个模块,不同的模块负责不同的功能,并且不同模块的代码独立进行编写,这时整个Gradle项目就会存在多个子项目:
1 | gradle-kotlin |
可以看到,在根项目下,只存在settings.gradle.kts
用于全局配置,而具体的build.gradle.kts
构建文件存在于各个子项目中分别进行编写。
我们也可以按照这样的结构去搭建我们的多模块项目。
项目创建
要创建一个多模块项目,我们可以先使用IDEA创建一个简单的Gradle项目出来,我们还是使用之前学习的那个gradle项目。
接着我们删除不需要的内容,比如:src
目录、build.gradle.kts
文件等,接着右键最外层项目,创建一个新的子项目,此时我们需要选择最外层项目为我们的父项目:
创建完成后,我们可以打开最外层的settings.gradle.kts
文件,IDEA已经自动为我们添加了模块引入:
1 | rootProject.name = "gradle-kotlin" |
此时,父子项目的层级已经明确划分出来了:
可以看到,build.gradle.kts
现在由子模块进行配置,每个子模块都可以单独处理。同理,新建chat-service模块
在存在多个子项目的时候,我们可以直接在根项目中执行指令,会生效于全部的子项目:
可以看到,这里的项目名称前面都加了一个:
符号。
新建一个commons模块
1 | include("auth-service") |
我们也可以配置项目之间的依赖,我们只需在dependencies
中进行配置:
1 | dependencies { |
有些时候,我们可能需要将一些部分统一进行配置,比如配置代码仓库地址,以及项目用到的插件,我们可以直接在根项目创建一个build.gradle.kts
来统一编写内容:
1 | subprojects { //subprojects表示对所有的子项目生效 还有一个allprojects,包含自己 |
这样,我们即使不在子项目中编写这些,就可以直接得到根项目的配置:
1 | dependencies { |
依赖的传递
我们在使用多模块时可能会遇到这样的一个问题,现在有三个模块,并且具有以下依赖关联:
- service-a
- service-b implementation(service-a)
- service-c implementation(service-b)
此时,从链式的依赖关系上来看,它们长这样:service-a -> service-b -> service-c
按照正常的传递关系来说,在B中应该是可以直接使用A中定义的内容的,因为依赖了A模块,同时,由于C依赖了B模块,那么理所应当,C也应该可以直接使用A中定义的内容,我们来看看是否真的如此:
1 | //A模块中定义 |
1 | //B模块中定义 |
1 | //C模块中定义 |
这就很奇怪了,在Maven中是完全可以实现传递依赖的,为什么到Gradle就不行了呢?这是因为implementation
不支持依赖传递,因此,即使我们改变了B模块的依赖,此时C也无法通过传递的形式得到B包含的依赖,由于不需要处理传递依赖,在编译时只需要处理一层,因此速度会非常快,大部分情况下非常推荐使用implementation
来进行依赖导入。
如果各位小伙伴需要实现传递依赖的效果,我们需要使用另一个插件提供的方法来导入依赖:
1 | plugins { |
此时,模块B的依赖由于使用了api进行导入,我们在模块C中无论是使用api
导入还是implementation
导入B,都可以使用B中api函数导入的依赖了。
使用buildSrc模块
在Gradle中有一个特殊机制,我们可以创建一个名为buildSrc
的模块,它支持我们自己定义能够在kts
脚本中使用的内容。
但是我们发现报错了,为什么呢?因为这个模块比较特殊,他不能被其他模块包含,他自动就会被加载。
接着我们修改一下buildSrc模块的build.gradle.kts
文件:
1 | plugins { |
此时我们就可以编写我们需要使用的部分了,比如我们希望吧阿里云Maven仓库封装成一个函数的形式,直接使用,就像mavenCentral()
那样,不然每次都要写一个完整地址,很麻烦,这里我们直接开一个新的kt文件编写扩展函数:
1 | import org.gradle.api.artifacts.dsl.RepositoryHandler |
接着,我们就可以在其他的kts脚本中使用我们定义的内容了,比如根项目的配置:
1 | subprojects { |
是不是感觉很方便?我们也可以使用这种方式定义所有需要使用的依赖版本,实现统一管理,比如编译版本的管理:
1 | import org.gradle.api.JavaVersion |
1 | subprojects { |
包括如果我们需要使用一些第三方的依赖,也可以统一管理版本:
1 | object Version { |
1 | dependencies { |
除了以上用法之外,我们也可以在buildSrc模块中编写自定义的插件并使用,这里我们创建一个新的插件类:
1 | import org.gradle.api.Plugin |
接着我们需要在buildSrc的构建脚本中声明此插件:
1 | gradlePlugin { |
声明之后,我们就可以在项目中使用了:
1 | plugins { |
利用插件,我们可以快速为项目添加各种任务,这里我们魔改一下上面写的插件:
1 | class MyPlugin: Plugin<Project> { |
此时项目中已经存在我们自定义的两个任务了: