# Gradle 依赖&解决依赖冲突
- 如何定义一个依赖。
- DependencyHandler,Dependency,Dependencies,Configuration,ConfigurationContainer 的关系。
- 什么是传递依赖?
- 如何定位依赖冲突?
- 如何解决依赖冲突?
- provided ,runtime 和 compile 三者区别?
# 如何定义依赖
在 Gradle 中常见的依赖类型有几种有 3 种,下面一一列举:
dependencies {
//方式1: 依赖一个 project
compile project(":common")
//方式2: 依赖一个本地 jar 包
compile files('libs/aliyun-vod-croe-android-sdk-1.0.0.jar')
//方式2 扩展:通过 fileTree 指定 dir 依赖所有的 jar 包
compile fileTree(dir: 'libs', include: ['*.jar'])
//方式3: 依赖一个远程仓库的包
compile 'com.android.support:appcompat-v7:26.1.0'
}
# DependencyHandler
当我们点击
compile
时,发现跟不进去源码。那么是不是表示compile
本不是类属性或者方法呢?
- project 的 dependencies 源代码
通过阅读注释,可以知道
dependencies
接受的是一个 closure ,并且参数类型为DependencyHandler
。那么要关注闭包具备的功能,那么就要关注DependencyHandler
可以做什么事?
/**
* <p>Configures the dependencies for this project.
*
* <p>This method executes the given closure against the {@link DependencyHand
* DependencyHandler} is passed to the closure as the closure's delegate.
*
* <h3>Examples:</h3>
* See docs for {@link DependencyHandler}
*
* @param configureClosure the closure to use to configure the dependencies.
*/
void dependencies(Closure configureClosure);
- 一组依赖的是如何表示的?
我们可以在 DependencyHandler 中找到下面这样的定义方式,那么就可以明白,我们上面写的
compile
对应于 configurationName ,而值就是对应于 dependencyNotation,我们可以将其看做是 key-value的关系,一组(configurationName,dependencyNotation)就表示一个 Configuration 对象。
dependencies {
configurationName dependencyNotation1,dependencyNotation2
}
- 依赖底层的调用代码
其实 DependencyHandler 源码中有很多相关的方法,我这里列举一个 add 方法,我们通过
compile 'com.android.support:appcompat-v7:26.1.0'
其实底层应该调用就是 add 方法,对应的 configurationName 为compile
而 dependencyNotation 就是'com.android.support:appcompat-v7:26.1.0'
/**
* Adds a dependency to the given configuration.
*
* @param configurationName The name of the configuration.
* @param dependencyNotation
*
* The dependency notation, in one of the notations described above.
* @return The dependency.
*/
Dependency add(String configurationName, Object dependencyNotation);
/**
* Adds a dependency to the given configuration, and configures the dependency using the given closure.
*
* @param configurationName The name of the configuration.
* @param dependencyNotation The dependency notation, in one of the notations described above.
* @param configureClosure The closure to use to configure the dependency.
* @return The dependency.
*/
Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure);
- 通过
add
方法实现依赖
该方法的第三参数是一个闭包,它是对 Configuration 的一个配置,闭包类型是 ModuleDependency ,你可以在这里做一些你想要的配置,例如是支持传递依赖等,详细可以查看
ModuleDependency
的源码。
add('compile', 'org.hibernate:hibernate-core:3.6.3.Final')
{
ModuleDependency dependency ->
//(1). 指定传递依赖
//dependency.transitive = true
//(2)exclude 对某一个库排除传递依赖
//exclude group: 'org.slf4j', module: 'slf4j-api'
}
- 几个相关类的关系图
依赖关系以下图表示的是 Dependency,Dependencies,DependencyHandler,Configuration,ConfigurationContainer 的关系。
# 什么是传递依赖?
- 图示传递依赖
传递依赖下面通过一个图来表示传递依赖,如果 transitive 为 true 表示支持传递依赖,那么 projectC 将可以依赖 projectA 的内容,其中传递依赖是不好的,因为你无法确定被依赖的库什么时候发生了更新,可能会因为更新,导致依赖失败等问题,不过 Gradle 默认是传递依赖的。
# 如何定位依赖冲突?
- 了解如何定位依赖冲突问题之前,我们先手动制造一个依赖冲突。
我们在 build.gradle 引入两个依赖库:
compile 'org.hibernate:hibernate-core:3.6.3.Final'
compile 'org.slf4j:slf4j-api:1.7.22'
执行一下命令查看依赖报告:
./gradlew :module:dependencies --configuration compile
Gradle 执行结果:
compile - Compile dependencies for 'main' sources (deprecated: use 'implementation' instead).
+--- 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(版本自动提升)
\--- org.slf4j:slf4j-api:1.7.22
从上面的执行结果可以看出:Gradle 在构建时,默认会使用最高版本的库,例如依赖 slf4j 最终都会以最高的版本为主。
- Configuration 配置依赖问题
我们前面介绍过,每一个 dependency 依赖都是 Configuration ,那么我们可以遍历ConfigurationContainer,获取 每一个 Configuration 对象,然后处理对应的依赖冲突问题。
下面我们配置,当 Gradle 构建遇到依赖冲突时,就立即构建失败:
configurations.all() {
Configuration configuration ->
//当遇到版本冲突时直接构建失败
configuration.resolutionStrategy.failOnVersionConflict()
}
在点击 build 时,会出现如下错误:
Gradle依赖冲突# 如何解决依赖冲突?
在上面依赖的两个库导致的依赖冲突是因为 slf4j 的版本不同导致的,那么我们知道原因之后就可以在依赖时指定不要传入依赖某一个库即可,下面来演示一下如何操作:
- 排除传递依赖
compile 'org.slf4j:slf4j-api:1.7.22'
compile ('org.hibernate:hibernate-core:3.6.3.Final'){
//排除某一个库(slf4j)依赖
exclude group: 'org.slf4j',module: 'slf4j-api'
}
- 下面就是排除传递依赖后的结果:
compile - Compile dependencies for 'main' sources (deprecated: use 'implementation' instead).
+--- org.slf4j:slf4j-api:1.7.22
\--- 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
- 指定禁止传递依赖
compile('org.hibernate:hibernate-core:3.6.3.Final') {
//指定禁止传递依赖
transitive false
}
compile 'org.slf4j:slf4j-api:1.7.22'
- 查看依赖报告
compile - Compile dependencies for 'main' sources (deprecated: use 'implementation' instead).
+--- org.hibernate:hibernate-core:3.6.3.Final
\--- org.slf4j:slf4j-api:1.7.22
- 当遇到依赖冲突时,指定一个版本号
configurations.all() {
Configuration configuration ->
configuration.resolutionStrategy.force(['org.slf4j:slf4j-api:1.6.1'])
//或者这样写
resolutionStrategy.setForcedModules(['org.slf4j:slf4j-api:1.6.1'])
}
# provided ,runtime 和 compile 三者区别?
compile : 依赖的包,编译并打包到最终的 apk 文件中。
provided : 依赖的包只参与编译而不会打包到最终的 apk 文件中。
runtime : 适用于依赖的包只作用在运行时而不需要在编译时。
dependencies {
//optional, help to generate the final application
provided('com.tencent.tinker:tinker-android-anno:1.9.1')
//tinker's main Android lib
compile('com.tencent.tinker:tinker-android-lib:1.9.1')
}
tinker依赖为应用生成 application 类,那么这个是一个 java 文件的生成,因此只需要在编译阶段去生成即可,而在运行时已经有这个生成的类了。
# 总结
上面是我学习了 Grade 依赖相关知识后的一点点总结,通过了解 Gradle 的依赖,从而能正确的处理每一个库的依赖关系。
记录于 2018-08-13 晚
网友评论