Gradle 是一款Google 推出的基于JVM、通用灵活的项目构建工具，支持Maven，JCenter 多种第三方仓库;支持传递性依赖管理、废弃了繁杂的xml 文件，转而使用简洁的、支持多种语言(例如：java、groovy 等)的build 脚本文件。
官网地址: https://gradle.org/
认识init.d 文件夹
我们可以在gradle 的init.d目录下创建以.gradle 结尾的文件，.gradle 文件可以实现在build 开始之前执行，所以你可以在这个文件配置一些你想预先加载的操作。
在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 文件的方法有：
1.在命令行指定文件,例如：gradle --init-script yourdir/init.gradle -q taskName。你可以多次输入此命令来指定多个init文件
2.把init.gradle文件放到USER_HOME/.gradle/ 目录下
3.把以.gradle结尾的文件放到USER_HOME/.gradle/init.d/ 目录下
4.把以.gradle结尾的文件放到GRADLE_HOME/init.d/ 目录下
如果存在上面的4种方式的2种以上，gradle会按上面的1-4序号依次执行这些文件，如果给定目录下存在多个init脚本，会按拼音a-z顺序执行这些脚本，每个init脚本都存在一个对应的gradle实例,你在这个文件中调用的所有方法和属性，都会委托给这个gradle实例，每个init脚本都实现了Script接口。
拓展2：仓库地址说明
mavenLocal(): 指定使用maven本地仓库，而本地仓库在配置maven时settings文件指定的仓库位置。如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目录,那么可不可以将gradle caches指向maven repository。我们说这是不行的，caches下载文件不是按照maven仓库中存放的方式。
拓展3：阿里云仓库地址请参考：https://developer.aliyun.com/mvn/guide
Gradle Wrapper 实际上就是对Gradle 的一层包装，用于解决实际开发中可能会遇到的不同的项目需要不同版本的Gradle
问题。例如：把自己的代码共享给其他人使用，可能出现如下情况:
这时候，我们就可以考虑使用Gradle Wrapper 了。这也是官方建议使用Gradle Wrapper 的原因。实际上有了Gradle Wrapper 之后，我们本地是可以不配置Gradle 的,下载Gradle 项目后，使用gradle 项目自带的wrapper 操作也是可以的。
那如何使用Gradle Wrapper 呢？
当然,我们也可在终端执行gradlew 指令时，指定指定一些参数,来控制Wrapper 的生成，比如依赖的版本等，如下：
具体操作如下所示：
GradleWrapper 的执行流程：
gradle-wrapper.properties 文件解读:
注意：前面提到的GRALE_USER_HOME 环境变量用于这里的Gradle Wrapper 下载的特定版本的gradle 存储目录。如果我们没有配置过GRALE_USER_HOME 环境变量,默认在当前用户家目录下的.gradle 文件夹中。
那什么时候选择使用gradle wrapper、什么时候选择使用本地gradle?
测试任务自动检测并执行测试源集中的所有单元测试。测试执行完成后会生成一个报告。支持JUnit 和TestNG 测试。
默认测试目录及标准输出
Junit 使用
Gradle 对于Junit4.x 支持
dependencies {
testImplementation group: 'junit' ,name: 'junit', version: '4.12'
}
test {
useJUnit()
}
Gradle 对于Junit5.x 版本支持
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
}
test {
useJUnitPlatform()
}
注意：无论是Junt4.x 版本还是Junit5.x 版本，我们只需在build.gradle 目录下执行gradle test 指令，gradle 就会帮我们执行所有的加了@Test 注解的测试，并生成测试报告。
包含和排除特定测试
test {
enabled true
useJUnit()
include 'com/**'
exclude 'com/abc/**'
}
gradle 在junit 中的批量测试,可以设置包含或者排除某些特定测试。
Gradle 项目的生命周期分为三大阶段: Initialization -> Configuration -> Execution. 每个阶段都有自己的职责,具体如下
图所示:
Initialization阶段主要目的是初始化构建, 它又分为两个子过程,一个是执行Init Script,另一个是执行Setting Script。
init.gradle 文件会在每个项目build 之前被调用，用于做一些初始化的操作，它主要有如下作用：
配置内部的仓库信息（如公司的maven 仓库信息）；
配置一些全局属性；
配置用户名及密码信息（如公司仓库的用户名和密码信息）。
Setting Script 则更重要, 它初始化了一次构建所参与的所有模块。
Configuration 阶段：这个阶段开始加载项目中所有模块的Build Script。所谓"加载" 就是执行build.gradle 中的语句,
根据脚本代码创建对应的task, 最终根据所有task 生成由Task 组成的有向无环图(Directed Acyclic Graphs)，如下:
从而构成如下有向无环树：
Execution 阶段：这个阶段会根据上个阶段构建好的有向无环图，按着顺序执行Task【Action 动作】。
首先对settings 文件的几点说明：
1、作用：主要是在项目初始化阶段确定一下引入哪些工程需要加入到项目构建中,为构建项目工程树做准备。
2、工程树：gradle 中有工程树的概念，类似于maven 中的project 与module。
3、内容：里面主要定义了当前gradle 项目及子project 的项目名称
4、位置：必须放在根工程目录下。
5、名字：为settings.gradle 文件，不能发生变化
6、对应实例：与org.gradle.api.initialization.Settings 实例是一一对应的关系。每个项目只有一个settings 文件。
7、关注：作为开发者我们只需要关注该文件中的include 方法即可。使用相对路径【: 】引入子工程。
8.一个子工程只有在setting 文件中配置了才会被gradle 识别,这样在构建的时候才会被包含进去。案例如下所示：
//根工程项目名
rootProject.name = ‘root’
//包含的子工程名称
include ‘subject01’
include ‘subject02’
include ‘subject03’
//包含的子工程下的子工程名称
include ‘subject01:subproject011’
include ‘subject01:subproject012’
项目名称中":" 代表项目的分隔符, 类似路径中的"/“. 如果以”:" 开头则表示相对于root project 。然后Gradle 会
为每个带有build.gradle 脚本文件的工程构建一个与之对应的Project 对象。
项目实质上是Task 对象的集合。一个Task 表示一个逻辑上较为独立的执行过程，比如编译Java 源代码，拷贝文件，
打包Jar 文件，甚至可以是执行一个系统命令。另外，一个Task 可以读取和设置Project 的Property 以完成特定的操作。
可参考官方文档：https://docs.gradle.org/current/userguide/tutorial_using_tasks.html
让我们来先看一个例子:
task A {
println "root taskA"
doFirst(){
println "root taskA doFirst"
}
doLast(){
println "root taskA doLast"
}
}
在文件所在的目录执行命令: gradle A。
配置阶段完成执行阶段完成，并且doFirst 在doLast 执行之前执行。配置阶段执行,任务的行为在执行阶段执行案例如下：doFirst、doLast 两个方法可以在任务内部定义，也可以在任务外部定义
def map=new HashMap<String,Object>();
//action属性可以设置为闭包，设置task自身的行为
map.put("action",{println "taskD.."})
task(map,"a"){
description 'taskA description....'
group "atguigu"
//在task内部定义doFirst、doLast行为
doFirst {
def name = 'doFirst..'
println name
}
doLast {
def name = 'doLast..'
println name
}
}
//在task外部定义doFirst、doLast行为
a.doFirst {
println it.description
}
a.doLast {
println it.group
}
测试：gradle a 输出如下所示：
底层原理分析：无论是定义任务自身的action,还是添加的doLast、doFirst 方法，其实底层都被放入到一个Action 的List中了
最初这个action List 是空的，当我们设置了action【任务自身的行为】,它先将action 添加到列表中，此时列表中只有一个action,后续执行doFirst 的时候doFirst 在action 前面添加，执行doLast 的时候doLast 在action 后面添加。
doFirst永远添加在actions List 的第一位，保证添加的Action 在现有的action List 元素的最前面；doLast 永远都是在action List末尾添加，保证其添加的Action 在现有的action List 元素的最后面。一个往前面添加,一个往后面添加，最后这个actionList 就按顺序形成了doFirst、doSelf、doLast 三部分的Actions,就达到doFirst、doSelf、doLast 三部分的Actions 顺序执行的目的。
提示1:其中<<代表doLast,在gradle5.x 版本之后就废弃,不能使用了,如下所示:
如下所示：
task hello << {
println 'Hello world!'
}
Task 之间的依赖关系可以在以下几部分设置：
方式一：参数方式依赖
task A {
doLast {
println "TaskA.."
}
}
task 'B'{
doLast {
println "TaskB.."
}
}
//参数方式依赖: dependsOn后面用冒号
task 'C'(dependsOn: ['A','B']){
doLast {
println "TaskC.."
}
}
方式二:内部依赖
//参数方式依赖
task 'C' {
//内部依赖：dependsOn后面用= 号
dependsOn= [A,B]
doLast {
println "TaskC.."
}
}
方式三：外部依赖
//外部依赖:可变参数,引号可加可不加
C.dependsOn(B,'A')
当然：task 也支持跨项目依赖
在subproject01 工程的build.gradle 文件中定义:
task A {
doLast {
println "TaskA.."
}
}
在subproject02 工程的build.gradle 文件中定义:
task B{
dependsOn(":subproject01:A") //依赖根工程下的subject01中的任务A ：跨项目依赖。
doLast {
println "TaskB.."
}
}
拓展1：当一个Task 依赖多个Task 的时候，被依赖的Task 之间如果没有依赖关系，那么它们的执行顺序是随机的,并无影响。
拓展2：重复依赖的任务只会执行一次,比如：
A->B、C
B->C
任务A 依赖任务B 和任务C、任务B 依赖C 任务。执行任务A 的时候，显然任务C 被重复依赖了，C 只会执行一次。
任务执行语法：gradle [taskName...] [--option-name...]。
| 分类 | 解释 |
|---|---|
| 常见的任务（*） | gradle build: 构建项目:编译、测试、打包等操作 gradle run :运行一个服务,需要application 插件支持，并且指定了主启动类才能运行 gradle clean: 请求当前项目的build 目录 gradle init : 初始化gradle 项目使用 gradle wrapper:生成wrapper 文件夹的。 gradle wrapper 升级wrapper 版本号：gradle wrapper --gradle-version=4.4 gradle wrapper --gradle-version 5.2.1 --distribution-type all :关联源码用 |
| 项目报告相关任务 | gradle projects : 列出所选项目及子项目列表，以层次结构的形式显示 gradle tasks: 列出所选项目【当前project,不包含父、子】的已分配给任务组的那些任务。 gradle tasks --all :列出所选项目的所有任务。 gradle tasks --group=“build setup”:列出所选项目中指定分组中的任务。 gradle help --task someTask :显示某个任务的详细信息 gradle dependencies :查看整个项目的依赖信息，以依赖树的方式显示 gradle properties 列出所选项目的属性列表 |
| 调试相关选项 | -h,–help: 查看帮助信息 -v, --version:打印Gradle、Groovy、Ant、JVM 和操作系统版本信息。 -S, --full-stacktrace:打印出所有异常的完整(非常详细)堆栈跟踪信息。 -s,–stacktrace: 打印出用户异常的堆栈跟踪(例如编译错误)。 -Dorg.gradle.daemon.debug=true: 调试Gradle 守护进程。 -Dorg.gradle.debug=true:调试Gradle 客户端(非daemon)进程。 -Dorg.gradle.debug.port=(port number):指定启用调试时要侦听的端口号。默认值为5005。 |
| 性能选项: 【备注:在gradle.properties 中指定这些选项中的许多选项，因此不需要命令行标志】 |
–build-cache, --no-build-cache： 尝试重用先前版本的输出。默认关闭(off)。 –max-workers: 设置Gradle 可以使用的woker 数。默认值是处理器数。 -parallel, --no-parallel: 并行执行项目。有关此选项的限制，请参阅并行项目执行。 默认设置为关闭(off) |
| 守护进程选项 | –daemon, --no-daemon: 使用Gradle 守护进程运行构建。默认是on –foreground:在前台进程中启动Gradle 守护进程。 -Dorg.gradle.daemon.idletimeout=(number of milliseconds): Gradle Daemon 将在这个空闲时间的毫秒数之后停止自己。默认值为10800000(3 小时)。 |
| 日志选项 | -Dorg.gradle.logging.level=(quiet,warn,lifecycle,info,debug): 通过Gradle 属性设置日志记录级别。 -q, --quiet: 只能记录错误信息 -w, --warn: 设置日志级别为warn -i, --info: 将日志级别设置为info -d, --debug:登录调试模式(包括正常的堆栈跟踪) |
| 其它(*) | -x:-x 等价于: --exclude-task : 常见gradle -x test clean build –rerun-tasks: 强制执行任务，忽略up-to-date ,常见gradle build --rerun-tasks –continue: 忽略前面失败的任务,继续执行,而不是在遇到第一个失败时立即停止执行。每个遇到的故障都将在构建结束时报告，常见：gradle build --continue。 gradle init --type pom :将maven 项目转换为gradle 项目(根目录执行) gradle [taskName] :执行自定义任务 |
更详细请参考官方文档:
https://docs.gradle.org/current/userguide/command_line_interface.html#sec:command_line_executing_tasks
拓展：gradle 任务名是缩写: 任务名支持驼峰式命名风格的任务名缩写，如：connectTask 简写为：cT,执行任务gradle cT。
拓展1:前面提到的Gradle 指令本质:一个个的task[任务], Gradle 中所有操作都是基于任务完成的。
拓展2：gradle 默认各指令之间相互的依赖关系：
相关解释：
任务定义方式，总体分为两大类:一种是通过Project 中的task()方法,另一种是通过tasks 对象的create 或者register 方法。
task('A',{//任务名称,闭包都作为参数
println "taskA..."
})
task('B'){//闭包作为最后一个参数可以直接从括号中拿出来
println "taskB..."
}
task C{//groovy语法支持省略方法括号:上面三种本质是一种
println "taskC..."
}
def map=new HashMap<String,Object>();
map.put("action",{println "taskD.."}) //action属性可以设置为闭包
task(map,"D");
tasks.create('E'){//使用tasks的create方法
println "taskE.."
}
tasks.register('f'){ //注：register执行的是延迟创建。也即只有当task被需要使用的时候才会被创建。
println "taskF...."
}
当然：我们也可以在定义任务的同时指定任务的属性，具体属性有：
在定义任务时也可以给任务分配属性：定义任务的时候可以直接指定任务属性，也可以给已有的任务动态分配属性：
//①.F是任务名，前面通过具名参数给map的属性赋值,以参数方式指定任务的属性信息
task(group: "atguigu",description: "this is task B","F")
//②.H是任务名，定义任务的同时，在内部直接指定属性信息
task("H") {
group("atguigu")
description("this is the task H")
}
//③.Y是任务名，给已有的任务在外部直接指定属性信息
task "y"{}
y.group="atguigu"
clean.group("atguigu") //案例：给已有的clean任务重新指定组信息
可以在idea 中看到: 上面自定义的那几个任务和gradle 自带的clean 任务已经跑到：atguigu 组了。
前面我们定义的task 都是DefaultTask 类型的,如果要完成某些具体的操作完全需要我们自己去编写gradle 脚本，势必有
些麻烦，那有没有一些现成的任务类型可以使用呢？有的，Gradle 官网给出了一些现成的任务类型帮助我们快速完成想
要的任务，我们只需要在创建任务的时候，指定当前任务的类型即可，然后即可使用这种类型中的属性和API 方法了。
| 常见任务类型 | 该类型任务的作用 |
|---|---|
| Delete | 删除文件或目录 |
| Copy | 将文件复制到目标目录中。此任务还可以在复制时重命名和筛选文件。 |
| CreateStartScripts | 创建启动脚本 |
| Exec | 执行命令行进程 |
| GenerateMavenPom | 生成Maven 模块描述符(POM)文件。 |
| GradleBuild | 执行Gradle 构建 |
| Jar | 组装JAR 归档文件 |
| JavaCompile | 编译Java 源文件 |
| Javadoc | 为Java 类生成HTML API 文档 |
| PublishToMavenRepository | 将MavenPublication 发布到mavenartifactrepostal。 |
| Tar | 组装TAR 存档文件 |
| Test | 执行JUnit (3.8.x、4.x 或5.x)或TestNG 测试。 |
| Upload | 将Configuration 的构件上传到一组存储库。 |
| War | 组装WAR 档案。 |
| Zip | 组装ZIP 归档文件。默认是压缩ZIP 的内容。 |
提示1：如果想看更详细的gradle 自带Task 类型，请参考官方文档: https://docs.gradle.org/current/dsl/index.html
提示2: 官方文档在给出这些任务类型的时候，同时给出了案例代码，可以点进去上述官网地址中的某个类型中观看
具体使用例如：
tasks.register('myClean', Delete) {
delete buildDir
}
在命令行执行gradle myClean 发现就可以将当前project 的build 目录删除
当然除了gradle 自带的task 类型,我们也可以自定义task 类型，如下所示：
def myTask=task MyDefinitionTask (type: CustomTask)
myTask.doFirst(){
println "task 执行之前执行的doFirst方法"
}
myTask.doLast(){
println "task 执行之后执行的doLast方法"
}
class CustomTask extends DefaultTask {
//@TaskAction表示Task本身要执行的方法
@TaskAction
def doSelf(){
println "Task 自身在执行的in doSelf"
}
}
测试：gradle MyDefinitionTask
控制台输出：
在Gradle 中,有三种方式可以指定Task 执行顺序：
1、dependsOn 强依赖方式
2、通过Task 输入输出
3、通过API 指定执行顺序
详细请参考官网：https://docs.gradle.org/current/dsl/org.gradle.api.Task.html
gradle 的强大功能不仅仅用于定义任务的功能。例如，可以使用它在循环中注册同一类型的多个任务
4.times { counter ->
tasks.register("task$counter") {
doLast {
println "I'm task number $counter"
}
}
}
一旦注册了任务,就可以通过API 访问它们。例如，您可以使用它在运行时动态地向任务添加依赖项。Ant 不允许这样
的事情发生。
4.times { counter ->
tasks.register("task$counter") {
doLast {
println "I'm task number $counter"
}
}
}
tasks.named('task0') { dependsOn('task2', 'task3') }
构建4 个任务,但是任务0 必须依赖于任务2 和3,那么代表任务2 和3 需要在任务0 之前优先加载。具体测试如下:
每个任务都有一个enabled 默认为的标志true。将其设置为false 阻止执行任何任务动作。禁用的任务将标记为“跳过”。
task disableMe {
doLast {
println 'This task is Executing...'
}
enabled(true)//直接设置任务开启，默认值为true
}
//disableMe.enabled = false //设置关闭任务
每个任务都有一个timeout 可用于限制其执行时间的属性。当任务达到超时时，其任务执行线程将被中断。该任务将
被标记为失败。终结器任务仍将运行。如果–continue 使用，其他任务可以在此之后继续运行。不响应中断的任务无法
超时。Gradle 的所有内置任务均会及时响应超时
task a() {
doLast {
Thread.sleep(1000)
println "当前任务a执行了"
}
timeout = Duration.ofMillis(500)
}
task b() {
doLast {
println "当前任务b执行了"
}
}
在控制台使用: gradle a b测试会发现执行a 的时候,由于a 执行超时，抛出异常，所以没有继续往下执行【b 也没执行】。
然后在控制台使用:gradle a b –continue,测试会发现a 虽然执行失败，但是b 还是执行了。
常用的任务查找方法有：
task atgege {
doLast {
println "xxx"
}
}
//根据任务名查找
tasks.findByName("xxx").doFirst({println "xxx...."})
tasks.getByName("xxx").doFirst({println "xxx...."})
//根据任务路径查找【相对路径】
tasks.findByPath(":xxx").doFirst({println "xxx...."})
tasks.getByPath(":xxx").doFirst({println "xxx...."})
当我们执行、依赖一个不存在的任务时，Gradle 会执行失败,报错误信息。那我们能否对其进行改进,当执行一个不存在
的任务时，不是报错而是打印提示信息呢？
task hello {
doLast {
println 'hello xxx'
}
}
tasks.addRule("对该规则的一个描述，便于调试、查看等"){
String taskName -> task(taskName) {
doLast {
println "该${taskName}任务不存在，请查证后再执行"
}
}
}
测试: 使用gradle abc hello 进行测试,此时当abc 任务不存在时，也不会报异常【不中断执行】而是提示自定义的规则信 息，继续执行hello 任务。此外，它还可以根据不同的规则动态创建需要的任务等情况。
断言就是一个条件表达式。Task 有一个onlyIf 方法。它接受一个闭包作为参数，如果该闭包返回true 则该任务执行， 否则跳过。这有很多用途，比如控制程序哪些情况下打什么包，什么时候执行单元测试，什么情况下执行单元测试的时
候不执行网络测试等。具体案例如下所示：
task hello {
doLast {
println 'hello 尚硅谷的粉丝们'
}
}
hello.onlyIf { !project.hasProperty('fensi') }
Gradle 允许您定义一个或多个在没有指定其他任务时执行的默认任务。
代码如下所示：
defaultTasks 'myClean', 'myRun'
tasks.register('myClean'){
doLast {
println 'Default Cleaning!'
}
}
tasks.register('myRun') {
doLast {
println 'Default Running!'
}
}
tasks.register('other') {
doLast {
println "I'm not a default task!"
}
}
几种常见的文件操作方式：
各种文件操作类型的详细介绍如下所示：
使用Project.file(java.lang.Object)方法，通过指定文件的相对路径或绝对路径来对文件的操作,其中相对路径为相对当前
project[根project 或者子project]的目录。其实使用Project.file(java.lang.Object)方法创建的File 对象就是Java 中的File 对象，我们可以使用它就像在Java 中使用一样。示例代码如下：
//使用相对路径
File configFile = file('src/conf.xml')
configFile.createNewFile();
// 使用绝对路径
configFile = file('D:\\conf.xml')
println(configFile.createNewFile())
// 使用一个文件对象
configFile = new File('src/config.xml')
println(configFile.exists())
文件集合就是一组文件的列表, 在Gradle 中, 文件集合用FileCollection 接口表示。我们可以使用
Project.files(java.lang.Object[])方法来获得一个文件集合对象，如下代码创建一个FileCollection 实例：
def collection = files('src/test1.txt',new File('src/test2.txt'),['src/test3.txt', 'src/test4.txt'])
collection.forEach(){File it ->
it.createNewFile() //创建该文件
println it.name //输出文件名
}
Set set1 = collection.files // 把文件集合转换为java中的Set类型
Set set2 = collection as Set
List list = collection as List// 把文件集合转换为java中的List类型
for (item in list) {
println item.name
}
def union = collection + files('src/test5.txt') // 添加或者删除一个集合
def minus = collection - files('src/test3.txt')
union.forEach(){File it ->
println it.name
}
对于文件集合我们可以遍历它；也可以把它转换成java 类型；同时还能使用+来添加一个集合，或使用-来删除集合。
文件树是有层级结构的文件集合,一个文件树它可以代表一个目录结构或一ZIP 压缩包中的内容结构。文件树是从文件集
合继承过来的,所以文件树具有文件集合所有的功能。我们可以使用Project.fileTree(java.util.Map)方法来创建文件树对象，
还可以使用过虑条件来包含或排除相关文件。示例代码如下：
tree = fileTree('src/main').include('**/*.java')// 第一种方式:使用路径创建文件树对象，同时指定包含的文件
//第二种方式:通过闭包创建文件树:
tree = fileTree('src/main') {
include '**/*.java'
}
tree = fileTree(dir: 'src/main', include: '**/*.java') //第三种方式:通过路径和闭包创建文件树：具名参数给map传值
tree = fileTree(dir: 'src/main', includes: ['**/*.java', '**/*.xml', '**/*.txt'], exclude: '**/*test*/**')
tree.each {File file -> // 遍历文件树的所有文件
println file
println file.name
}
我们可以使用Copy 任务来拷贝文件，通过它可以过虑指定拷贝内容，还能对文件进行重命名操作等。Copy 任务必须指
定一组需要拷贝的文件和拷贝到的目录，这里使用CopySpec.from(java.lang.Object[])方法指定原文件；使用
CopySpec.into(java.lang.Object)方法指定目标目录。示例代码如下
task copyTask(type: Copy) {
from 'src/main/resources'
into 'build/config'
}
from()方法接受的参数和文件集合时files()一样。当参数为一个目录时，该目录下所有的文件都会被拷贝到指定目录下（目 录自身不会被拷贝）；当参数为一个文件时，该文件会被拷贝到指定目录；如果参数指定的文件不存在，就会被忽略； 当参数为一个Zip 压缩文件，该压缩文件的内容会被拷贝到指定目录。
into()方法接受的参数与本地文件时file()一样。示例代码如下
task copyTask(type: Copy) {
// 拷贝src/main/webapp目录下所有的文件
from 'src/main/webapp'
// 拷贝单独的一个文件
from 'src/staging/index.html'
// 从Zip压缩文件中拷贝内容
from zipTree('src/main/assets.zip')
// 拷贝到的目标目录
into 'build/explodedWar'
}
在拷贝文件的时候还可以添加过虑条件来指定包含或排除的文件，示例如下：
task copyTaskWithPatterns(type: Copy) {
from 'src/main/webapp'
into 'build/explodedWar'
include '**/*.html'
include '**/*.jsp'
exclude { details -> details.file.name.endsWith('.html') }
}
在拷贝文件的时候还可以对文件进行重命名操作，示例如下：
task rename(type: Copy) {
from 'src/main/webapp'
into 'build/explodedWar'
// 使用一个闭包方式重命名文件
rename { String fileName ->
fileName.replace('-staging-', '')
}
}
在上面的例子中我们都是使用Copy 任务来完成拷贝功能的，那么有没有另外一种方式呢？答案是肯定的，那就是
Project.copy(org.gradle.api.Action)方法。下面示例展示了copy()方法的使用方式：
task copyMethod {
doLast {
copy {
from 'src/main/webapp'
into 'build/explodedWar'
include '**/*.html'
include '**/*.jsp'
}
}
}
或者使用project 对象的copy 方法:
copy {
//相对路径或者绝对路径
from file('src/main/resources/ddd.txt') //file也可以换成new File()
into this.buildDir.absolutePath
}
执行gradle build 指令即可。去build 目录的本地磁盘查看，就能看到。
通常一个项目会有很多的Jar 包，我们希望把项目打包成一个WAR，ZIP 或TAR 包进行发布，这时我们就可以使用
Zip，Tar，Jar，War 和Ear 任务来实现，不过它们的用法都一样，所以在这里我只介绍Zip 任务的示例。
首先，创建一个Zip 压缩文件,并指定压缩文件名称，如下代码所示：
apply plugin: 'java'
version=1.0
task myZip(type: Zip) {
from 'src/main‘
into ‘build’ //保存到build目录中
baseName = 'myGame'
}
println myZip.archiveName
执行命令gradle -q myZip，输出结果为：
> gradle -q myZip
myGame-1.0.zip
最后，我们可以使用Project.zipTree(java.lang.Object)和Project.tarTree(java.lang.Object)方法来创建访问Zip 压缩包的文
件树对象，示例代码如下：
// 使用zipTree
FileTree zip = zipTree('someFile.zip')
// 使用tarTree
FileTree tar = tarTree('someFile.tar')
在这里，我们介绍了Gradle 对本地文件、文件集合、文件树、文件拷贝和归档文件的操作方式。更详细的请参考官方
文档：https://docs.gradle.org/current/userguide/working_with_files.html
Gradle 中的依赖分别为直接依赖，项目依赖，本地jar 依赖。
案例如下：
dependencies {
//①.依赖当前项目下的某个模块[子工程]
implementation project(':subject01')
//②.直接依赖本地的某个jar文件
implementation files('libs/foo.jar', 'libs/bar.jar')
//②.配置某文件夹作为依赖项
implementation fileTree(dir: 'libs', include: ['*.jar'])
//③.直接依赖
implementation 'org.apache.logging.log4j:log4j:2.17.2'
}
直接依赖：在项目中直接导入的依赖，就是直接依赖
implementation ‘org.apache.logging.log4j:log4j:2.17.2’
上面是简写法，完整版写法如下：
implementation group: ‘org.apache.logging.log4j’, name: ‘log4j’, version: ‘2.17.2’
group/name/version 共同定位一个远程仓库,version 最好写一个固定的版本号，以防构建出问题，implementation 类似
maven 中的依赖的scope,对比maven 中的依赖:
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
<scope>compile</scope>
</dependency>
</dependencies>
项目依赖: 从项目的某个模块依赖另一个模块
implementation project(‘:subject01’)
这种依赖方式是直接依赖本工程中的libary module，这个libary module 需要在setting.gradle 中配置。
本地jar 依赖：本地jar 文件依赖，一般包含以下两种方式
//直接依赖某文件
implementation files('libs/foo.jar', 'libs/bar.jar')
//配置某文件夹作为依赖项
implementation fileTree(dir: 'libs', include: ['*.jar'])
当执行build 命令时，gradle 就会去配置的依赖仓库中下载对应的Jar，并应用到项目中。
类似于Maven 的scope 标签，gradle 也提供了依赖的类型,具体如下所示:
官方文档参考：
https://docs.gradle.org/current/userguide/java_library_plugin.html#java_library_plugin: 各个依赖范围的关系和说明
https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal : 依赖范围升级和移除
https://docs.gradle.org/current/userguide/java_library_plugin.html#java_library_plugin：API 和implemention 区别
https://docs.gradle.org/current/userguide/java_plugin.html#java_plugin: 执行java 命令时都使用了哪些依赖范围的依赖。
提示1：java 插件提供的功能，java-library 插件都提供。
如下所示：
拓展3:api 和implementation 案例分析
api 的适用场景是多module 依赖，moduleA 工程依赖了module B，同时module B 又需要依赖了module C，modelA 工
程也需要去依赖module C,这个时候避免重复依赖module,可以使用module B api 依赖的方式去依赖module C,modelA 工
程只需要依赖moduleB 即可。
总之，除非涉及到多模块依赖，为了避免重复依赖，咱们会使用api,其它情况我们优先选择implementation，拥有大量
的api 依赖项会显著增加构建时间。
依赖冲突是指"在编译过程中, 如果存在某个依赖的多个版本, 构建系统应该选择哪个进行构建的问题",如下所示:
A、B、C 都是本地子项目module，log4j 是远程依赖。
编译时： B 用1.4.2 版本的log4j，C 用2.2.4 版本的log4j,B 和C 之间没有冲突
打包时： 只能有一个版本的代码最终打包进最终的A对应的jar |war包，对于Gradle 来说这里就有冲突了
案例演示：我们在build.gradle 引入依赖库
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
implementation 'org.hibernate:hibernate-core:3.6.3.Final'
}
修改build.gradle
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
implementation 'org.hibernate:hibernate-core:3.6.3.Final'
implementation 'org.slf4j:slf4j-api:1.4.0'
}
如上所示：默认下，Gradle 会使用最新版本的jar 包【考虑到新版本的jar 包一般都是向下兼容的】，实际开发中，还
是建议使用官方自带的这种解决方案。当然除此之外，Gradle 也为我们提供了一系列的解决依赖冲突的方法: exclude
移除一个依赖，不允许依赖传递，强制使用某个版本。
Exclude 排除某个依赖
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
implementation('org.hibernate:hibernate-core:3.6.3.Final'){
//排除某一个库(slf4j)依赖:如下三种写法都行
exclude group: 'org.slf4j'
exclude module: 'slf4j-api'
exclude group: 'org.slf4j',module: 'slf4j-api'
}
//排除之后,使用手动的引入即可。
implementation 'org.slf4j:slf4j-api:1.4.0'
}
不允许依赖传递
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
implementation('org.hibernate:hibernate-core:3.6.3.Final'){
//不允许依赖传递，一般不用
transitive(false)
}
//排除之后,使用手动的引入即可
implementation 'org.slf4j:slf4j-api:1.4.0'
}
在添加依赖项时,如果设置transitive 为false,表示关闭依赖传递。即内部的所有依赖将不会添加到编译和运行时的类路径。
强制使用某个版本
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
implementation('org.hibernate:hibernate-core:3.6.3.Final')
//强制使用某个版本!!【官方建议使用这种方式】
implementation('org.slf4j:slf4j-api:1.4.0!!')
//这种效果和上面那种一样,强制指定某个版本
implementation('org.slf4j:slf4j-api:1.4.0'){
version{
strictly("1.4.0")
}
}
}
我们可以先查看当前项目中到底有哪些依赖冲突：
//下面我们配置，当Gradle 构建遇到依赖冲突时，就立即构建失败
configurations.all() {
Configuration configuration ->
//当遇到版本冲突时直接构建失败
configuration.resolutionStrategy.failOnVersionConflict()
}
简单的说,通过应用插件我们可以:
1.促进代码重用、减少功能类似代码编写、提升工作效率
2.促进项目更高程度的模块化、自动化、便捷化
3.可插拔式的的扩展项目的功能
在项目构建过程中做很多事情，把插件应用到项目中，通常可以完成:
1、可以添加任务【task】到项目中，从而帮助完成测试、编译、打包等。
2、可以添加依赖配置到项目中。
3、可以向项目中拓展新的扩展属性、方法等。
4、可以对项目进行一些约定，如应用Java 插件后，约定src/main/java 目录是我们的源代码存在位置，编译时编译这个
目录下的Java 源代码文件。
第一种：脚本插件
脚本插件的本质就是一个脚本文件，使用脚本插件时通过apply from:将脚本加载进来就可以了，后面的脚本文件可以是
本地的也可以是网络上的脚本文件，下面定义一段脚本，我们在build.gradle 文件中使用它，具体如下：
//version.gradle文件
ext {
company= "xx"
cfgs = [
compileSdkVersion : JavaVersion.VERSION_1_8
]
spring = [
version : '5.0.0'
]
}
下面将将在构建文件中使用这个脚本文件，具体如下:
//build.gradle文件
//map作为参数
apply from: 'version.gradle'
task taskVersion{
doLast{
println "公司名称为：${company},JDK版本是${cfgs.compileSdkVersion},版本号是${spring.version}"
}
}
上述代码的执行结果如下：
意义：脚本文件模块化的基础，可按功能把我们的脚本进行拆分一个个公用、职责分明的文件，然后在主脚本文件引用，
比如：将很多共有的库版本号一起管理、应用构建版本一起管理等。
第二种：对象插件之内部插件[核心插件]
二进制插件[对象插件]就是实现了org.gradle.api.Plugin 接口的插件，每个Java Gradle 插件都有一个plugin id。
可通过如下方式使用一个Java 插件：
apply plugin : ‘java’ //map具名参数方式
或者：
//也可以使用闭包作为project.apply方法的一个参数
apply{
plugin 'java'
}
通过上述代码就将Java 插件应用到我们的项目中了，对于Gradle 自带的核心插件都有唯一的plugin id，其中java 是
Java 插件的plugin id,这个plugin id 必须是唯一的，可使用应用包名来保证plugin id 的唯一性。这里的java 对应的
具体类型是org.gradle.api.plugins.JavaPlugin，所以可以使用如下方式使用Java 插件：
//使用方式1：Map具名参数,全类名
apply plugin:org.gradle.api.plugins.JavaPlugin
//org.gradle.api.plugins默认导入：使用方式2
apply plugin:JavaPlugin
apply plugin: 'java' //核心插件，无需事先引入，使用方式3:插件的id
Gradle 中提供的二进制插件【核心插件】,可参考: https://docs.gradle.org/current/userguide/plugin_reference.html
第二种：对象插件之第三方插件
如果是使用第三方发布的二进制插件，一般需要配置对应的仓库和类路径,
//使用传统的应用方式
buildscript {
ext {
springBootVersion = "2.3.3.RELEASE"
}
repositories {
mavenLocal()
maven { url 'http://maven.aliyun.com/nexus/content/groups/public' }
jcenter()
}
// 此处先引入插件
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
//再应用插件
apply plugin: 'org.springframework.boot' //社区插件,需要事先引入，不必写版本号
但是如果是第三方插件已经被托管在https://plugins.gradle.org/ 网站上，就可以不用在buildscript 里配置classpath
依赖了，直接使用新出的plugins DSL 的方式引用，案例如下：
使用plugins DSL 方式
plugins {
id 'org.springframework.boot' version '2.4.1'
}
注意：
1.如果使用老式插件方式buildscript{}要放在build.gradle 文件的最前面,而新式plugins{}没有该限制。
2.托管在网站gradle 插件官网的第三方插件有两种使用方式，一是传统的buildscript 方式，一种是plugins DSL 方式。
第二种：对象插件之用户自定义插件
interface GreetingPluginExtension {
Property<String> getMessage()
Property<String> getGreeter()
}
class GreetingPlugin implements Plugin<Project> {
void apply(Project project) {
def extension = project.extensions.create('greeting', GreetingPluginExtension)
project.task('hello') {
doLast {
println "${extension.message.get()} from ${extension.greeter.get()}"
}
}
}
}
apply plugin: GreetingPlugin
// Configure the extension using a DSL block
greeting {
message = 'Hi'
greeter = 'Gradle'
}
参考地址：https://docs.gradle.org/current/userguide/custom_plugins.html
我们直接执行hello 任务./gradle hello 即可,这种方式实现的插件我们一般不使用，因为这种方式局限性太强，只能本
Project，而其他的Project 不能使用。
代码参考：
//指定使用什么版本的JDK语法编译源代码,跟编译环境有关,在有java插件时才能用
sourceCompatibility = 1.8
//指定生成特定于某个JDK版本的class文件:跟运行环境有关,在有java插件时才能用
targetCompatibility = 1.8
//业务编码字符集,注意这是指定源码解码的字符集[编译器]
compileJava.options.encoding "UTF-8"
//测试编码字符集,注意这是指定源码解码的字符集[编译器]
compileTestJava.options.encoding "UTF-8"
//编译JAVA文件时采用UTF-8:注意这是指定源码编码的字符集【源文件】
tasks.withType(JavaCompile) {
options.encoding = "UTF-8"
}
//编译JAVA文件时采用UTF-8:注意这是指定文档编码的字符集【源文件】
tasks.withType(Javadoc) {
options.encoding = "UTF-8"
}
提示1：group+name+version 类似于maven 的group+artifactId+version
提示2：encoding 解决业务代码与测试代码中文乱码问题
repositories {
//gradle中会按着仓库配置的顺序，从上往下依次去对应的仓库中找所需要的jar包:
//如果找到，则停止向下搜索，如果找不到，继续在下面的仓库中查找
//指定去本地某个磁盘目录中查找:使用本地file文件协议:一般不用这种方式
maven { url 'file:///D:/repos/mavenrepos3.5.4'}
maven { url "$rootDir/lib/release" }
//指定去maven的本地仓库查找
mavenLocal()
//指定去maven的私服或者第三方镜像仓库查找
maven { name "Alibaba" ; url "https://maven.aliyun.com/repository/public" }
maven { name "Bstek" ; url "https://nexus.bsdn.org/content/groups/public/" }
//指定去maven的远程仓库查找:即https://repo.maven.apache.org/maven2/
mavenCentral()
//去google仓库查找
google()
}
因为Gradle 没有自己的远程仓库，而是使用Maven、jcenter、jvy、google 这些远程仓库。
allprojects 是对所有project(包括Root Project+ child Project[当前工程和所有子工程])的进行统一配置，而subprojects
是对所有Child Project 的进行统一配置。
测试如下：
allprojects {
tasks.create('hello') {
doLast {
task ->
println "project name is $task.project.name"
}
}
}
subprojects {
hello.doLast{
task->
println "here is subprojects $task.project.name"
}
}
通常在subprojects 和allprojects 中:
allprojects(){ //本质Project中的allprojects方法，传递一个闭包作为参数。
apply plugin: 'java'
ext {
junitVersion = '4.10'
..
}
task allTask{
...
}
repositories {
...
}
dependencies {
...
}
}
subprojects(){
…//同上面allprojects中的方法。
}
拓展1: 如果是直接在根project 配置repositories 和dependencies 则只针对根工程有效。
拓展:我们也可以在对单个Project 进行单独配置：
project('subject01') {
task subject01 {
doLast {
println 'for subject01'
}
}
}
执行gradle build 指令即可查看测试效果。
Project 和Task 都允许用户添加额外的自定义属性，要添加额外的属性，通过应用所属对象的ext 属性即可实现。添加
之后可以通过ext 属性对自定义属性读取和设置，如果要同时添加多个自定义属性,可以通过ext 代码块:
//自定义一个Project的属性
ext.age = 18
//通过代码块同时自定义多个属性
ext {
phone = 19292883833
address="北京尚硅谷"
}
task extCustomProperty {
//在task中自定义属性
ext {
desc = "奥利给"
}
doLast {
println "年龄是：${age}"
println "电话是：${phone}"
println "地址是：${address}"
println "尚硅谷：${desc}"
}
}
测试：通过gradle extCustomProperty
输出结果为：
年龄是：18
电话是：19292883833
地址是：北京尚硅谷
尚硅谷：奥利给
拓展1: ext 配置的是用户自定义属性，而gradle.properties 中一般定义系统属性、环境变量、项目属性、JVM 相关配置
信息。例如
gradle.properties 文件案例：加快构建速度的，gradle.properties 文件中的属性会自动在项目运行时加载。
## 设置此参数主要是编译下载包会占用大量的内存，可能会内存溢出
org.gradle.jvmargs=-Xms4096m -Xmx8192m
## 开启gradle缓存
org.gradle.caching=true
#开启并行编译
org.gradle.parallel=true
#启用新的孵化模式
org.gradle.configureondemand=true
#开启守护进程
org.gradle.daemon=true
详细请参考：https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_configuration_properties
buildscript 里是gradle 脚本执行所需依赖，分别是对应的maven 库和插件。
案例如下：
import org.apache.commons.codec.binary.Base64
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath group: 'commons-codec', name: 'commons-codec', version: '1.2'
}
}
tasks.register('encode') {
doLast {
def byte[] encodedString = new Base64().encode('hello world\n'.getBytes())
println new String(encodedString)
}
}
需要注意的是：
//老式apply插件的引用方式,使用apply+buildscript
buildscript {
ext {
springBootVersion = "2.3.3.RELEASE"
}
repositories {
mavenLocal()
maven { url 'http://maven.aliyun.com/nexus/content/groups/public' }
jcenter()
}
//此处引入插件
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'java' //核心插件，无需事先引入
apply plugin: 'org.springframework.boot' //社区插件，需要事先引入,才能应用，不必写版本号
接下来,将咱们写好的模块发布发布到公司的私服以供别人使用,如下所示：
plugins {
id 'java-library' //如果发布war包，需要war插件,java-library支持带源码、文档发布
id 'maven-publish'
}
//带源码和javadoc的发布:需要'java-library'插件支持:它是java的升级版，java插件的功能java-library都有
//javadoc.options.encoding="UTF-8"
//java {
// withJavadocJar()
// withSourcesJar()
//}
publishing {
publications {
myLibrary(MavenPublication) {
groupId = 'org.gradle.sample' //指定GAV坐标信息
artifactId = 'library'
version = '1.1'
from components.java//发布jar包
//from components.web///引入war插件，发布war包
}
}
repositories {
//本地仓库位于USER_HOME/.m2/repository
mavenLocal()
//发布项目到私服中
maven {
name = 'myRepo' //name属性可选,表示仓库名称，url必填
//发布地址:可以是本地仓库或者maven私服
//url = layout.buildDirectory.dir("repo")
// change URLs to point to your repos, e.g. http://my.org/repo
def releasesRepoUrl = layout.buildDirectory.dir('repos/releases')
def snapshotsRepoUrl = layout.buildDirectory.dir('repos/snapshots')
url = version.endsWith('SNAPSHOT') ? snapshotsRepoUrl : releasesRepoUrl
//认证信息:用户名和密码
// credentials {
// username = 'joe'
// password = 'secret'
// }
}
}
}
执行发布命令，将项目发布到本地仓库或者远程仓库。常见的发布指令有：
generatePomFileForPubNamePublication: 生成pom 文件
publishPubNamePublicationToRepoNameRepository:发布项目到指定仓库,如果没有仓库名，默认为maven
publishPubNamePublicationToMavenLocal: 将PubName 发布复制到本地Maven 仓库中包括POM 文件和其他元数据。
publish: 发布到repositories 中指定的仓库(为比如Maven 私服)
publishToMavenLocal: 执行所有发布任务中的操作发布到本地maven 仓库【默认在用户家目录下的.m2/repository】。
生命周期中的这些钩子函数都是由gradle 自动回调完成的,利用这些钩子函数可以帮助我们实现一些我们想要的功能。
Gradle 在生命周期各个阶段都提供了用于回调的钩子函数:
Gradle 初始化阶段:
Gradle 配置阶段:
虽然beforeEvalute 属于project 的生命周期, 但是此时build script 尚未被加载, 所以beforeEvaluate 的设置依
然要在init script 或setting script 中进行,不要在build script 中使用project.beforeEvaluate 方法。
Gradle 执行阶段:
当所有的Task 执行完毕后，会回调Gradle 对象的buildFinish 方法。
提示：Gradle 执行脚本文件的时候会生成对应的实例，主要有如下几种对象：
1、Gradle 对象：在项目初始化时构建，全局单例存在，只有这一个对象
2、Project 对象：每一个build.gradle文件都会转换成一个Project 对象,类似于maven中的pom.xml文件
3、Settings 对象：settings.gradle 会转变成一个settings 对象,和整个项目是一对一的关系,一般只用到include方法
4.、Task对象: 从前面的有向无环图中，我们也可以看出，gradle最终是基于Task的,一个项目可以有一个或者多个Task
钩子函数代码演示：项目目录结构如下：
在root project 的settings.gradle 文件中添加：
gradle.settingsEvaluated { //1.settingsEvaluated钩子函数,在初始化阶段完成
println "settingsEvaluated"
}
gradle.projectsLoaded { //2.projectsLoaded钩子函数,在初始化阶段完成
println "projectsLoaded"
}
//声明一个变量：表示当前项目名,在每次执行某个项目的beforeEvaluate方法时先给projectName变量赋值
//这样方便在：gradle.beforeProject和afterProject两个钩子函数使用。
def projectName=""
gradle.addProjectEvaluationListener( new ProjectEvaluationListener(){
//3.执行各个project的beforeEvaluate：在配置阶段完成
@Override
void beforeEvaluate(Project project) {
projectName=project.name
println "${project.name} Project beforeEvaluate"
}
//5.执行各个project的afterEvaluate：在配置阶段完成
@Override
void afterEvaluate(Project project, ProjectState projectState) {
println "${project.name} Project afterEvaluate"
}
});
gradle.beforeProject {//4.执行各个project的beforeProject：在配置阶段完成
println "${projectName} beforeProject..."
}
gradle.afterProject {//6.执行各个project的afterProject：在配置阶段完成
println "${projectName} afterProject..."
}
//7.所有工程的build.gradle 执行完毕后，回调Gradle 对象的projectsEvaluated 方法：在配置阶段完成
def rootProjectName=rootProject.getName()
gradle.projectsEvaluated {
println "${rootProjectName} projectsEvaluated..."
}
//8.配置阶段完毕后，回调TaskExecutionGraph 对象的whenReady 方法：在配置阶段完成
gradle.taskGraph.whenReady {
println "${rootProjectName} taskGraph whenReady..."
}
//9.在当前Task执行之前,会回调TaskExecutionGraph 对象的beforeTask方法：在执行阶段完成
gradle.taskGraph.beforeTask {task ->
println "this is the task ${task.name} of the project ${task.getProject().name} beforeTask.."
}
//10.在当前Task执行之后,会回调TaskExecutionGraph 对象的afterTask方法：在执行阶段完成
gradle.taskGraph.afterTask {task ->
println "this is the task ${task.name} of the project ${task.getProject().name} afterTask.."
}
//11.当所有的Task 执行完毕后，会回调Gradle 对象的buildFinish 方法：在执行阶段完成
gradle.buildFinished {
println "${rootProjectName} buildFinished..."
}
在root 的build.gradle 文件中添加:
task A {
println "root taskA"
doFirst(){
println "root taskA doFirst"
}
doLast(){
println "root taskA doLast"
}
}
在subject01 的build.gradle 文件中添加:
task B {
println "SubProject01 taskB"
doFirst(){
println "SubProject01 taskB doFirst"
}
doLast(){
println "SubProject01 taskB doLast"
}
}
在subject02 的build.gradle 文件中添加:
//task C在上面
task C{
//依赖task D
dependsOn 'D'
println "SubProject02 taskC"
doFirst(){
println "SubProject02 taskC doFirst"
}
doLast(){
println "SubProject02 taskC doLast"
}
}
//task D在下面
task D {
println "SubProject02 taskD"
doFirst(){
println "SubProject02 taskD doFirst"
}
doLast(){
println "SubProject02 taskD doLast"
}
}
测试：在root 工程的根目录执行：gradle C .就能看到gradle 生命周期的三个阶段，及每个阶段执行的钩子函数、还有在
执行阶段有依赖关系的任务的执行顺序问题。
拓展1：在settings.gradle 中添加监听器，查看task 有向无环图:
gradle.taskGraph.addTaskExecutionGraphListener(new TaskExecutionGraphListener() {
@Override //生成有向无环图
void graphPopulated(TaskExecutionGraph taskExecutionGraph) {
taskExecutionGraph.allTasks.forEach(task->{//核心逻辑:通过taskExecutionGraph获得所有的task
taskExecutionGraph.allTasks.forEach(releaseTask->{
println "尚硅谷:" + releaseTask.getProject().name + ":" + releaseTask.name
})
})
}
})
测试：在root 工程根目录下执行：gradle C。查看测试结果：
拓展2: 计算Gradle 构建过程中各个阶段的耗时:需要注意，这里只是计算了初始化阶段的settings 文件，并没有计算
init.gradle 初始化的时间。
def projectName=rootProject.getName() //定义项目名
long beginOfSetting = System.currentTimeMillis() //初始化阶段开始时间
def beginOfConfig //配置阶段开始时间
def configHasBegin = false //配置阶段是否开始了，只执行一次
def beginOfProjectConfig = new HashMap() //存放每个build.gradle 执行之前的时间
def beginOfTaskExecute //执行阶段开始时间
gradle.projectsLoaded { //初始化阶段执行完毕
println "${projectName}工程初始化总耗时${System.currentTimeMillis() - beginOfSetting} ms"
}
//build.gradle 执行前
gradle.beforeProject {Project project ->
if(!configHasBegin){
configHasBegin = true
beginOfConfig = System.currentTimeMillis()
}
beginOfProjectConfig.put(project,System.currentTimeMillis())
}
//build.gradle 执行后
gradle.afterProject {Project project ->
def begin = beginOfProjectConfig.get(project)
if(project.name == projectName) {
println "根工程${projectName} 配置阶段耗时：${System.currentTimeMillis() - begin} ms"
}else{
println "子工程${project.name} 配置阶段耗时：${System.currentTimeMillis() - begin} ms"
}
}
gradle.taskGraph.whenReady {//配置阶段完毕
println "整个${projectName}项目在配置阶段总耗时：${System.currentTimeMillis() - beginOfConfig} ms"
beginOfTaskExecute = System.currentTimeMillis()
}
//执行阶段开始
gradle.taskGraph.beforeTask {Task task ->
task.doFirst {
task.ext.beginOfTask = System.currentTimeMillis()
}
task.doLast {
println "${task.name}在执行阶段耗时：${System.currentTimeMillis() - task.ext.beginOfTask} ms"
}
}
gradle.buildFinished {//执行阶段完毕
println " 执行阶段总耗时：${System.currentTimeMillis() - beginOfTaskExecute} ms"
println " 整个构建过程耗时：${System.currentTimeMillis() - beginOfSetting} ms"
}
Spring Boot Gradle 插件在Gradle 提供Spring Boot 支持。它允许您打包可执行jar 或war 归档文件，运行Spring Boot 应用程序，并使用Spring-Boot-dependencies 提供的依赖管理。相关文档请参考：https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#running-your-application
该插件发布在Gradle 的插件门户网站上，可以使用插件块来应用:
plugins {
id 'org.springframework.boot' version '2.3.7.RELEASE' //维护springboot版本号,不单独使用,和下面两个插件一起用
id 'io.spring.dependency-management' version '1.0.10.RELEASE'
//进行依赖管理,在引入其它boot依赖时省略版本号、解决jar包冲突问题
id 'java'
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter'
implementation 'org.springframework.boot:spring-boot-starter-web' //省略版本,原生bom支持,插件management提供
testImplementation('org.springframework.boot:spring-boot-starter-test') {
exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
}
}
test {
useJUnitPlatform()
}
要想运行当前Springboot 项目，直接执行gradle bootRun 指令或者idea 右侧按钮即可。
当然如果想让当前项目打成可执行jar 包，只需执行： gradle bootJar 指令即可。
Cloud 项目创建也可以借助于脚手架创建，与Boot 项目类似。
buildscript {
repositories {
maven { url 'https://maven.aliyun.com/repository/public' }
}
dependencies {
classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.4.1'
}
}
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'