在gradle项目中，尤其是在多模块配置中，依赖管理是一个核心且复杂的话题。当一个模块依赖另一个模块，或直接依赖某个库时，这些依赖可能会引入其自身的传递性依赖。如果多个路径引入了同一个库的不同版本，gradle会根据其默认的依赖解析策略来选择一个版本。通常，gradle会选择版本号最高的那个依赖，但这并非总是理想的，有时旧版本会以某种方式“潜入”项目，导致意外的行为或冲突。
例如，在一个多模块项目中，adapters模块依赖main模块，而main模块可能通过某个库隐式地引入了io.r2dbc:r2dbc-postgresql:0.8.12.RELEASE。即使adapters模块显式声明了runtimeOnly 'io.r2dbc:r2dbc-postgresql:0.8.13.RELEASE'，旧版本仍然可能存在于项目的外部库列表中，这表明旧版本并未被完全排除或覆盖。
识别冲突源要解决传递性依赖冲突，首先需要准确找出旧版本库是从何处引入的。Gradle提供了强大的工具来帮助我们分析依赖图：
- gradlew <moduleName>:dependencies: 这个命令会打印指定模块的完整依赖树。仔细检查输出，可以帮助你发现哪个直接依赖引入了你想要排除的传递性依赖。
- gradlew <moduleName>:dependencyInsight --dependency <dependencyName>: 这是更精确的工具。例如，运行./gradlew adapters:dependencyInsight --dependency r2dbc-postgresql，它会显示r2dbc-postgresql这个库在adapters模块中被引入的所有路径，以及最终被解析的版本。通过这个命令，你可以清晰地看到0.8.12.RELEASE版本是通过哪个依赖链条进入项目的。
// 示例：使用dependencyInsight命令 // 在项目根目录执行 ./gradlew adapters:dependencyInsight --dependency r2dbc-postgresql排除传递性依赖的策略
一旦识别出冲突源，就可以采取相应的策略来排除或强制使用特定版本的依赖。
1. 在特定依赖中排除最直接的方法是在引入传递性依赖的直接依赖声明中进行排除。如果知道main模块引入了旧版本的r2dbc-postgresql，并且adapters模块依赖main，那么可以在adapters模块的build.gradle中这样声明：
// build.gradle (adapters module)
dependencies {
implementation(project(":main")) {
// 排除main模块可能引入的r2dbc-postgresql
exclude group: 'io.r2dbc', module: 'r2dbc-postgresql'
}
// 然后再显式引入所需的版本
runtimeOnly 'io.r2dbc:r2dbc-postgresql:0.8.13.RELEASE'
} 或者，如果旧版本是由main模块内部的某个库引入的，你也可以在main模块的build.gradle中对其直接依赖进行排除：
// build.gradle (main module)
dependencies {
// 假设某个libraryA引入了旧版r2dbc-postgresql
implementation('com.example:libraryA:1.0.0') {
exclude group: 'io.r2dbc', module: 'r2dbc-postgresql'
}
// 如果需要，可以在main模块中引入新版本
// runtimeOnly 'io.r2dbc:r2dbc-postgresql:0.8.13.RELEASE'
} 注意事项：用户尝试的exclude(group = 'io.r2dbc', module = 'r2dbc-postgresql')之所以无效，很可能是因为它没有被放置在具体的依赖声明块中，或者没有指定要排除的配置。exclude必须作用于一个特定的依赖声明，告诉Gradle在解析该依赖的传递性依赖时忽略某个库。
2. 全局排除（针对所有配置）如果你希望在整个项目中，或者至少在某个模块的所有配置中都排除某个库，可以使用configurations.all块：
// build.gradle (或根项目的build.gradle)
configurations.all {
exclude group: 'io.r2dbc', module: 'r2dbc-postgresql'
} 这种方法会阻止Gradle在任何配置（如implementation, runtimeOnly, testImplementation等）中解析io.r2dbc:r2dbc-postgresql的任何版本。之后，你需要显式地引入你想要使用的版本。
3. 使用依赖解析策略（Resolution Strategy）对于更复杂的版本冲突或需要强制使用特定版本的情况，Gradle的resolutionStrategy提供了强大的控制能力。
强制指定版本 (force): 这是最常用的策略之一，它会强制Gradle在所有依赖路径中都使用你指定的版本。
// build.gradle (或根项目的build.gradle)
configurations.all {
resolutionStrategy {
// 强制使用0.8.13.RELEASE版本
force 'io.r2dbc:r2dbc-postgresql:0.8.13.RELEASE'
}
} 使用force时，即使其他依赖引入了不同版本的r2dbc-postgresql，Gradle也会忽略它们，统一使用0.8.13.RELEASE。
更精细的控制 (eachDependency): eachDependency允许你对每个解析的依赖进行自定义处理，例如，当发现某个特定的依赖版本不符合预期时，可以动态地修改它。
// build.gradle (或根项目的build.gradle)
configurations.all {
resolutionStrategy {
eachDependency { DependencyResolveDetails details ->
// 如果依赖是r2dbc-postgresql，并且版本不是0.8.13.RELEASE，则强制为0.8.13.RELEASE
if (details.requested.group == 'io.r2dbc' && details.requested.name == 'r2dbc-postgresql') {
if (details.requested.version != '0.8.13.RELEASE') {
details.useVersion '0.8.13.RELEASE'
}
}
}
}
} 这种方法提供了最大的灵活性，但通常force已经足够解决大多数版本冲突问题。
Spring Dependency Management Plugin 的影响如果项目中使用了id "io.spring.dependency-management"插件，它会引入Spring Boot的BOM（Bill of Materials）来管理依赖版本。这意味着，如果你在dependencyManagement块中定义了r2dbc-postgresql的版本，或者Spring Boot的BOM本身就包含了它的版本，那么这个插件会在你显式声明版本时提供默认值。
当同时存在spring-dependency-management插件、模块内的显式版本声明和传递性依赖时，优先级通常是：
- 模块内的显式版本声明：如果你在dependencies块中明确指定了版本（例如runtimeOnly 'io.r2dbc:r2dbc-postgresql:0.8.13.RELEASE'），这通常会覆盖BOM中的版本。
- spring-dependency-management插件（BOM）：如果未显式声明版本，插件会根据BOM提供默认版本。
- 传递性依赖：如果上述两者都没有指定版本，Gradle会根据其默认规则解析传递性依赖。
在这种情况下，即使你显式声明了新版本，如果旧版本是通过某些特殊的传递路径（例如，一个没有被BOM管理的库）引入的，并且没有被正确排除，它仍然可能存在。因此，结合使用exclude或resolutionStrategy是确保单一版本一致性的关键。
总结解决Gradle多模块项目中的传递性依赖版本冲突，关键在于：
- 识别问题：使用gradlew dependencies和gradlew dependencyInsight准确找出旧版本库的来源。
-
选择策略：
- 对于特定依赖引入的旧版本，使用在依赖声明中排除 (exclude)。
- 对于需要全局统一版本的库，使用全局排除或更推荐的resolutionStrategy.force。
- 对于更复杂的场景，可以考虑resolutionStrategy.eachDependency。
- 验证结果：在应用更改后，再次运行gradlew <moduleName>:dependencies和gradlew <moduleName>:dependencyInsight，确认旧版本已被成功移除，并且项目使用的是期望的新版本。
通过这些方法，你可以有效地管理Gradle项目的依赖，避免版本冲突，确保项目的稳定性和可预测性。
以上就是Gradle多模块项目中的传递性依赖排除与版本管理的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。