【九月打卡】第十八天 依赖管理和解决版本冲突

第一模块：课程介绍

课程名称：新一代构建工具gradle
课程章节：第4章 高级应用
主讲老师：skyding

第二模块：课程内容

了解gradle的依赖版本管理和jar包的版本解决冲突

第三模块：课程收获

1. 熟悉build.gradle中的依赖说明

依赖的写法

首先看下依赖的写法：

testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'

这里使用冒号分隔的简短写法，第一个分号前面的是group，中间的是name，最后的数字就是版本号。

通过这个字符串我们就可以去代码仓库找到这个代码了。

repositories {
    mavenLocal()
    mavenCentral()
}

按照上面的这个配置，会先去MavenLocal去找jar包，如果没有找到，就去MavenCentral去找。

如果有私服的话，就这么写：

repositories {
    maven {
        url:'xxx'
    }
    mavenLocal()
    mavenCentral()
}

一般把url放在第一个。

传递性依赖

我们对依赖进行展开，可以看到它是一个树级结构。

可看到，Junit依赖了一些其他的依赖，那么如果还有其他的jar包也依赖了这些jar包的话，我们应该怎么解决呢？

解决版本冲突

我们先看一个版本的依赖栗子

在这个图片里面hibernate的commons模块依赖了slf4j，但是它自己也依赖了slf4j，那么这种情况下应该怎么处理呢？

1. 查看依赖报告
2. 排除传递性依赖
3. 强制一个版本

在gradle中，如果出现了版本冲突的时候，会自动使用最新的版本。

我们可以想修改默认解决策略

configurations.all{
	resolutionStrategy{
		failOnVersionConflict()
	}
}

这也在出现版本冲突的时候，就会直接报错了

那么当我们发现版本冲突的时候应该怎么做呢？

1. 排除传递性依赖

compile ('org.hibernate:hibernate-core:3.6.3.Final'){
	exclude group:" org.slf4j", module:"slf4j-api"
	//transitive = false
}

先把依赖添加进去

dependencies {
    implementation "org.hibernate:hibernate-core:3.6.3.Final"
    implementation "ch.qos.logback:logback-classic:1.2.11"
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
}

差看下依赖树

我们的项目里面现在有三个地方用到了slf4j这个依赖，但是这几个依赖都是1.7.32，gradle会自动帮我们使用最新的版本。

我们可以在help中执行dependencies来查看依赖树

runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.hibernate:hibernate-core:3.6.3.Final
|    +--- antlr:antlr:2.7.6
|    +--- commons-collections:commons-collections:3.1
|    +--- dom4j:dom4j:1.6.1
|    +--- org.hibernate:hibernate-commons-annotations:3.2.0.Final
|    |    \--- org.slf4j:slf4j-api:1.5.8 -> 1.7.32
|    +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final
|    +--- javax.transaction:jta:1.1
|    \--- org.slf4j:slf4j-api:1.6.1 -> 1.7.32
\--- ch.qos.logback:logback-classic:1.2.11
     +--- ch.qos.logback:logback-core:1.2.11
     \--- org.slf4j:slf4j-api:1.7.32

可以看到gradle将我们的依赖从1.5.8 -> 1.7.32，1.6.1 -> 1.7.32

来试试排除依赖。

    implementation('org.hibernate:hibernate-core:3.6.3.Final') {
        exclude group: "org.slf4j", module: "slf4j-api"
    }

查看下效果

runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.hibernate:hibernate-core:3.6.3.Final
|    +--- antlr:antlr:2.7.6
|    +--- commons-collections:commons-collections:3.1
|    +--- dom4j:dom4j:1.6.1
|    +--- org.hibernate:hibernate-commons-annotations:3.2.0.Final
|    +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final
|    \--- javax.transaction:jta:1.1
\--- ch.qos.logback:logback-classic:1.2.11
     +--- ch.qos.logback:logback-core:1.2.11
     \--- org.slf4j:slf4j-api:1.7.32

可以看到org.hibernate:hibernate-commons-annotations:3.2.0.Final下面的那个1.5.8版本的依赖已经不在了。

在试下指定依赖版本。

configurations.all {
    resolutionStrategy {
        failOnVersionConflict()
        force 'org.slf4j:slf4j-api:1.7.22'
    }
}

打印下看看

runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.hibernate:hibernate-core:3.6.3.Final
|    +--- antlr:antlr:2.7.6
|    +--- commons-collections:commons-collections:3.1
|    +--- dom4j:dom4j:1.6.1
|    +--- org.hibernate:hibernate-commons-annotations:3.2.0.Final
|    |    \--- org.slf4j:slf4j-api:1.5.8 -> 1.7.22
|    +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0.Final
|    +--- javax.transaction:jta:1.1
|    \--- org.slf4j:slf4j-api:1.6.1 -> 1.7.22
\--- ch.qos.logback:logback-classic:1.2.11
     +--- ch.qos.logback:logback-core:1.2.11
     \--- org.slf4j:slf4j-api:1.7.32 -> 1.7.22

这个时候就可以看到所有的依赖都变成了1.7.22了

那我们这样就解决了版本冲突了。

第四模块：课程记录