09、Gradle构建工具的依赖管理及版本冲突的解决

什么是依赖管理

几乎所有的基于JVM的软件项目都需要依赖外部类库来重用现有的功能。自动化的依赖管理可以明确依赖的版本，可以解决因传递性依赖带来的版本冲突。

坐标： group、name、version 这个三个属性决定唯一的一个jar包和maven同理

常用仓库：

• mavenLocal 本地仓库
• mavenCentral 公共的中央仓库
• jceter 也是一种公共的中央仓库
• 自定义仓库 也就是公司里的maven私服
• 文件仓库 本地机器的文件路径不推荐使用

自动化依赖管理

manager 就是构建工具，执行configuration构建脚本，第一次首先去远程仓库Remote repository下载jar包，放到Local repository本地仓库。构建项目使用jar包先去本地仓库获取，如果多次使用还会将jar包缓存。

依赖的阶段：

• compile 编译阶段 、runtime 运行时阶段
• testCompile 测试编译阶段 、testRuntime 测试运行时阶段

几个阶段的关系图

• 编译需要依赖的运行时都会依赖，运行时依赖的编译不会依赖
• 源代码依赖分测试代码也会依赖，测试代码依赖的源代码不一定依赖

测试编译阶段依赖配置

改成测试运行阶段依赖配置

可以验证上面的测试部分关系图，其余的不演示了。

仓库管理

1. mavenLocal()本地仓库配置
2. maven { url ‘私服地址’ } 私服配置方式
3. maven { url “http://maven.aliyun.com/nexus/content/groups/public/” } 配置国内镜像地址
4. 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

了解更多：