什么是依赖管理
几乎所有的基于JVM的软件项目都需要依赖外部类库来重用现有的功能。自动化的依赖管理可以明确依赖的版本,可以解决因传递性依赖带来的版本冲突。
坐标: group、name、version 这个三个属性决定唯一的一个jar包和maven同理
常用仓库:
- mavenLocal 本地仓库
- mavenCentral 公共的中央仓库
- jceter 也是一种公共的中央仓库
- 自定义仓库 也就是公司里的maven私服
- 文件仓库 本地机器的文件路径不推荐使用
自动化依赖管理
manager 就是构建工具,执行configuration构建脚本,第一次首先去远程仓库Remote repository下载jar包,放到Local repository本地仓库。构建项目使用jar包先去本地仓库获取,如果多次使用还会将jar包缓存。
依赖的阶段:
- compile 编译阶段 、runtime 运行时阶段
- testCompile 测试编译阶段 、testRuntime 测试运行时阶段
几个阶段的关系图
- 编译需要依赖的运行时都会依赖,运行时依赖的编译不会依赖
- 源代码依赖分测试代码也会依赖,测试代码依赖的源代码不一定依赖
测试编译阶段依赖配置
改成测试运行阶段依赖配置
可以验证上面的测试部分关系图,其余的不演示了。
仓库管理
- mavenLocal()本地仓库配置
- maven { url ‘私服地址’ } 私服配置方式
- maven { url “http://maven.aliyun.com/nexus/content/groups/public/” } 配置国内镜像地址
- mavenCentral() 默认的中央仓库
gradle加载jar包的顺序根据私服配置的顺序,在最上面的先使用没有向下找。
下图配置使用顺序:本地 > 私服 > 国内镜像 > 中央仓库
repositories {
mavenLocal()
maven { url '私服地址' }
maven { url "http://maven.aliyun.com/nexus/content/groups/public/" }
mavenCentral() // 调用闭包委托的mavenCentral()方法
}
版本冲突
下图是一个版本冲突的例子,出现了两个版本的 slf4j-api 。
解决版本冲突方式:
- 查看依赖报告
- 排除传递性依赖
- 强制使用一个版本
演示使用jar包
compile 'org.hibernate:hibernate-core:3.6.3.Final'
在Gradle中默认是解决方案是强制使用最高版本的jar包。
Gradle 自动帮我们解决了这冲突,在 gradle 的窗口里有一个 help 的分组,里面有个 dependencies 的任务双击执行可以看到具体的依赖和依赖更改报告。
如果想修改默认的解决策略,查看是什么地方发生了版本冲突可以直接让他构建失败看报错信息,修改代码如下。
configurations.all{
resolutionStrategy{
// 修改默认的解决策略
failOnVersionConflict()
}
}
加入配置后直接执行 build 任务,就会发现什么jar包发生了版本冲突,以及冲突的版本号。
使用排除传递性依赖的方式解决一下,排除传递性依赖里的 module 就是坐标里的 name 。
compile ('org.hibernate:hibernate-core:3.6.3.Final'){
exclude group:"org.slf4j", module:"slf4j-api"
}
修改完脚本后刷新一下,发现 hibernate 对 slf4j 的依赖没有了,这是执行 build 构建任务也成功了。
强制指定一个版本一般都是强制指定一个高版本
configurations.all{
resolutionStrategy{
// 修改不使用默认的解决策略
failOnVersionConflict()
// 强制指定一个版本
force 'org.slf4j:slf4j-api:1.7.24'
}
}
同样的操作修改完配置,刷新 build 可以成功。查看依赖报告都改成了我们指定的 1.7.24
了解更多: