网站首页 > 博客文章 正文
Gradle的学习
4.1 Gradle的优势
- 一款最新的,功能最强大的构建工具,用它逼格更高
- 使用Groovy或Kotlin代替XML,使用程序代替传统的XML配置,项目构建更灵活
- 丰富的第三方插件,让你随心所欲使用
- 完善Android,Java开发技术体系
4.2 Gradle的下载和安装
下载位置:
https://services.gradle.org/distributions/
PS:下载只有二进制文件的即可(bin那个压缩包)
4.3 配置环境变量
配置GRADLE_HOME:
配置Path:
验证Gradle是否安装成功:
4.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:
4.5 build.gradle构建脚本介绍
Gradle构建脚本中最重要的两个概念是project和Task,任何一个Gradle构建都由一个或者多个project组成每个project包括许多的构建部分,可以是一个jar包,也可以是一个web应用,也可以是多个jar的整合,可以部署应用和搭建环境.
如果有子项目的话:
每个项目,对应一个build.gradle的构建脚本
4.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的中央仓库
4.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之前执行这个逻辑'
}
4.6 Gradle项目构建生命周期
Gradle的生命周期分三个阶段:初始化阶段、配置阶段,、执行阶段。 初始化阶段 通过settings.gradlle判断有哪些项目需要初始化,加载所有需要初始化的项目的build.gradle文件并为每个项目创建project对象 配置阶段 执行各项目下的build.gradle脚本,完成project 的配置,并且构造Task任务依赖关系图以便在执行阶段按照依赖关系执行Task中的配置代码 执行阶段 通过配置阶段的Task图,按顺序执行需要执行的任务中的动作代码,就是执行任务中写在doFirst或doLast中的代码。
4.7 插件
4.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包中内容:
4.7.2 自定义插件
(1)在构建脚本中直接编写自定义插件:
但是上面的方法只能在当前脚本中使用,不可以在整个项目中使用,如果要想在整个项目中的所有构建脚本中都使用的话,需要将任务单独提取出来放入buildSrc下:
(2)自己创建buildSrc目录:
注意点:groovy目录创建好后一定要是蓝色的文件夹,如果是灰色的文件夹,需要自己构建build.gradle脚本,然后加入插件:
然后定义插件:
定义好以后,就可以在项目的所有build.gradle中使用了:
4.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'
}
}
4.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中对所有项目生效
猜你喜欢
- 2025-06-03 程序员简历例句—范例Java、Python、C++模板
- 2025-06-03 SQLREST工具的功能概述及使用指南
- 2025-06-03 SpringBoot一个提升N倍性能的操作
- 2025-06-03 Jeecgboot3.2版-postgres脚本制作
- 2025-06-03 心心念念的前端代码生成利器,前后端一网打尽
- 2025-06-03 基于Spring+SpringMVC+Mybatis分布式敏捷开发系统架构(附源码)
- 2025-06-03 拒绝MyBatis慢查询!性能优化实战手册
- 2025-06-03 有了 SPL,看来用不着 ORM 了(spl使用)
- 2025-06-03 SpringBoot整合MybatisPlus实现分页查询
- 2025-06-03 SpringBoot、MyBatis、Vue搭建一个Java企业应用开源框架源码分享
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- powershellfor (55)
- messagesource (56)
- aspose.pdf破解版 (56)
- promise.race (63)
- 2019cad序列号和密钥激活码 (62)
- window.performance (66)
- qt删除文件夹 (72)
- mysqlcaching_sha2_password (64)
- ubuntu升级gcc (58)
- nacos启动失败 (64)
- ssh-add (70)
- jwt漏洞 (58)
- macos14下载 (58)
- yarnnode (62)
- abstractqueuedsynchronizer (64)
- source~/.bashrc没有那个文件或目录 (65)
- springboot整合activiti工作流 (70)
- jmeter插件下载 (61)
- 抓包分析 (60)
- idea创建mavenweb项目 (65)
- vue回到顶部 (57)
- qcombobox样式表 (68)
- vue数组concat (56)
- tomcatundertow (58)
- pastemac (61)
本文暂时没有评论,来添加一个吧(●'◡'●)