1.1 Gradle的优势
-
一款最新的,功能最强大的构建工具,用它逼格更高
-
使用Groovy或Kotlin代替XML,使用程序代替传统的XML配置,项目构建更灵活
-
丰富的第三方插件,让你随心所欲使用
-
完善Android,Java开发技术体系
1.2 Gradle的下载和安装
下载位置:Gradle Distributions
PS:下载只有二进制文件的即可(bin那个压缩包)
1.3 配置环境变量
配置GRADLE_HOME:
配置Path:
验证Gradle是否安装成功:
1.4 创建第一个Gradle项目
标准项目结构:
项目打包:
执行:
如果出现乱码,在builde.gradle中加入配置:(更改后重新clean再build)
plugins { id 'java' } group 'com.msb' version '1.0-SNAPSHOT' repositories { mavenCentral() } dependencies { testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0' testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine' } test { useJUnitPlatform() } tasks.withType(JavaCompile) { options.encoding = "UTF-8" }
PS:
1.5 build.gradle构建脚本介绍
Gradle构建脚本中最重要的两个概念是project和Task,任何一个Gradle构建都由一个或者多个project组成每个project包括许多的构建部分,可以是一个jar包,也可以是一个web应用,也可以是多个jar的整合,可以部署应用和搭建环境.
如果有子项目的话:
每个项目,对应一个build.gradle的构建脚本
1.5.1 Project
一个project代表一个正在构建的组件(Jar/war文件),当构建开始时,Gradle会基于build.gradle实例化一个org.gradle.api.Project对象,并通过project变量来隐式调用其成员。
Project属性:
将build.gradle配置封装为一个Project对象,对象名字为project,通过project可以隐式调用:使用groovy语法
指定仓库位置:默认情况下使用的是中央仓库,此项目如果需要下载jar包从中央仓库中下载到本地目录(C:/Users/zss/.gradle) mavenCentral() 下载后的内容可以去:C:\Users\zss\.gradle\caches\modules-2\files-2.1中找 但是一般我们习惯使用maven本地仓库: 需要设置maven本地仓库:
进行环境变量设置:
重启IDEA打开,如果需要重新设置maven本地库位置:
PS:本地仓库的设置对新建项目是生效的
如果需要添加依赖,可以从中央仓库中查找坐标:
粘贴过来以后,点击刷新:
build.gradle中内容:
plugins { id 'java' } project.group = 'com.msb' version '1.0-SNAPSHOT' /* 指定仓库位置:默认情况下使用的是中央仓库,此项目如果需要下载jar包从中央仓库中下载到本地目录(C:/Users/zss/.gradle) mavenCentral() 下载后的内容可以去:C:\Users\zss\.gradle\caches\modules-2\files-2.1中找 但是一般我们习惯使用maven本地仓库: 需要设置maven本地仓库: */ repositories { mavenLocal() mavenCentral() } dependencies { testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0' testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine' // https://mvnrepository.com/artifact/org.mybatis/mybatis implementation group: 'org.mybatis', name: 'mybatis', version: '3.5.9' } test { useJUnitPlatform() } tasks.withType(JavaCompile) { options.encoding = "UTF-8" }
PS:Gradle没有自己的中央仓库,用的就是maven的中央仓库
1.5.2 Task
每个任务在构建执行过程中会被封装成org.gradle.api.Task对象,主要包括任务的动作和任务依赖,任务动作定义了一个原子操作,可以定义依赖其他任务、动作的顺序、执行的条件。
任务主要操作动作: dependsOn:依赖相关操作 doFirst :任务执行之前执行的方法 doLast、<<(老版本用,现在废弃了):任务执行之后执行的方法
定义好任务后,默认分配在other分组下:
也可以放在自定义的分组下:
任务的定义的方式:(6种定义方式)
plugins { id 'java' } project.group = 'com.msb' version '1.0-SNAPSHOT' /* 指定仓库位置:默认情况下使用的是中央仓库,此项目如果需要下载jar包从中央仓库中下载到本地目录(C:/Users/zss/.gradle) mavenCentral() 下载后的内容可以去:C:\Users\zss\.gradle\caches\modules-2\files-2.1中找 但是一般我们习惯使用maven本地仓库: 需要设置maven本地仓库: */ repositories { mavenLocal() mavenCentral() } dependencies { testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0' testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine' // https://mvnrepository.com/artifact/org.mybatis/mybatis implementation group: 'org.mybatis', name: 'mybatis', version: '3.5.9' } test { useJUnitPlatform() } tasks.withType(JavaCompile) { options.encoding = "UTF-8" } //自定义任务: //定义方式1: task(t1,{ group("mytask") //配置代码 println '我是任务1' //动作代码 doFirst { println '在任务t1执行前操作的动作代码' } //动作代码 doLast { println '在任务t1执行后操作的动作代码' } }) //定义方式2: task t2 { group("mytask") //配置代码 println '我是任务2' //动作代码 doFirst { println '在任务t2执行前操作的动作代码' } //动作代码 doLast { println '在任务t2执行后操作的动作代码' } } //定义方式3: tasks.create('t3'){ group("mytask") //配置代码 println '我是任务3' } //定义方式4: tasks.register('t4'){ group("mytask") //配置代码 println '我是任务4' } //定义方式5: tasks{ task t5{ group("mytask") //配置代码 println '我是任务5' } } //可以一次性定义多个任务-》动态任务定义: 3.times{index -> task("task${index}"){ group("mytask") //配置代码 println 'task${index}' } }
任务依赖:
//任务依赖: task a{ doFirst { println '我是任务a' } } task b(dependsOn:a){//代表b任务依赖a任务--->依赖方式通过参数传递 doFirst { println '我是任务b' } } task c{ dependsOn 'b' //依赖方式通过内部设置方式进行依赖 doFirst { println '我是任务c' } } task d{ doFirst { println '我是任务d' } } d.dependsOn c //依赖方式通过外部设置方式进行依赖
任务的执行时机:
在构建阶段,配置代码是不执行的,在执行阶段,执行动作代码
//通过tasks.register定义的任务,在build阶段的配置过程中不执行 //通过tasks.register定义的任务,在任务的执行阶段的配置过程中是执行的 //通过tasks.register定义的任务,配置代码的执行时机是落后于用task方式配置的
定位任务:对某个已有的任务进行扩展:例如对clean内置任务进行扩展
clean.doLast { println '我在clean之后执行这个逻辑' } tasks.named('clean').get().doFirst { println '我在clean之前执行这个逻辑' }
1.6 Gradle项目构建生命周期
Gradle的生命周期分三个阶段:初始化阶段、配置阶段,、执行阶段。 初始化阶段 通过settings.gradlle判断有哪些项目需要初始化,加载所有需要初始化的项目的build.gradle文件并为每个项目创建project对象 配置阶段 执行各项目下的build.gradle脚本,完成project 的配置,并且构造Task任务依赖关系图以便在执行阶段按照依赖关系执行Task中的配置代码 执行阶段 通过配置阶段的Task图,按顺序执行需要执行的任务中的动作代码,就是执行任务中写在doFirst或doLast中的代码。
1.7 插件
1.7.1 添加插件、发布和使用自定义jar包
案例:将自己的项目打成jar包,供给另外的项目使用
(1)新建一个Gradle项目:
(2)配置插件:
(3)然后刷新项目,刷新后任务中多了一个分组:
(4)配置发布分组:在build.gradle中配置:
(5)执行任务,发布jar包到本地仓库中:
(6)自行去本地库中查找你jar包和生成的配置文件:
C:\Users\zss.m2\repository\org\example\TestGradleJar
(7)在其它项目中使用刚才本地库中的jar包:
(8)验证:是否可以使用jar包中内容:
1.7.2 自定义插件
(1)在构建脚本中直接编写自定义插件:
但是上面的方法只能在当前脚本中使用,不可以在整个项目中使用,如果要想在整个项目中的所有构建脚本中都使用的话,需要将任务单独提取出来放入buildSrc下:
(2)自己创建buildSrc目录:
注意点:groovy目录创建好后一定要是蓝色的文件夹,如果是灰色的文件夹,需要自己构建build.gradle脚本,然后加入插件:
然后定义插件:
定义好以后,就可以在项目的所有build.gradle中使用了:
1.8 Gradle版本冲突问题
(1)依赖传递性:
假设你的项目依赖于一个库,而这个库又依赖于其他库。你不必自己去找出所有这些依赖,你只需要加上你直接依赖的库,Gradle会隐式的把这些库间接依赖的库也加入到你的项目中。
(2)传递性依赖中版本冲突:
由于传递性依赖的特点,两个不同版本的jar包会被依赖进来,这样就存在版本冲突的问题。
(3)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中依赖声明的顺序决定了谁会被解析使用。顺序最靠前的那个依赖优胜。
(4)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'
(5)Gradle中解决冲突的办法-手动修改依赖:
手动排除依赖:
dependencies { implementation(group: 'org.springframework', name: 'spring-jdbc', version: '5.1.3.RELEASE'){ exclude group:'org.springframework',module:'spring-beans' } }
后续可以自己手动配置你想要的版本的依赖。
修改默认配置策略,对所有jar不做冲突自动解决:
configurations.all{ resolutionStrategy{ failOnVersionConflict() } }
就会在构建时候抛出异常:
手动指定某个jar 的版本:
force:强制覆盖某个版本:
configurations.all{ resolutionStrategy{ force 'org.springframework:spring-beans:5.3.12' } }
1.9 多项目构建
在企业中,一个复杂的项目往往是分成几个小项目来协同完成的,这就涉及到多项目的构建,而多项目构建则需要把一个大项目进行项目模块化,通过模块的互相协作完成整个功能。在之前使用Maven的多项目构建时,一般需要一个root项目来统一管理所有的模块,Gradle也一样使用一个root项目来统一管理所有的模块。
案例:
构建:
配置:
配置1:统一插件配置:在根项目的build.gradle中配置:
//统一配置信息,包含root项目: allprojects{ //写法1: // plugins { // id 'java' // } //写法2: apply plugin : 'java' }
配置2:统一配置公共属性:
allprojects{ project.group = 'com.msb' version '1.0-SNAPSHOT' }
配置3:配置项目的依赖关系:在子项目的build.gradle中配置:
验证:
配置4:统一资源库:
subprojects{ repositories { mavenLocal() mavenCentral() } }
配置5:配置公用的依赖:配置在根项目的build.gradle中:
subprojects{ dependencies { testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0' testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine' } }
PS:如果配置在subprojects外面,就只针对根生效,对子项目无效,只有放在subprojects中对所有项目生效