两步,追踪传递依赖,然后将其从负责的库中排除。
gradle dependencies 为您提供包括传递的完整列表。如果您的项目很小,这可能会有所帮助,但对于大型企业构建......它的信息太多。请随意搜索,但我们会从dependencyInsight 获得更多相关信息。
gradle dependencyInsight --dependency someDependency 查找依赖项可能进入构建的所有位置。如果您有多个版本,这将有助于明确这些版本的来源。
在我的用例中,日志记录被明确声明为编译时依赖项,因此如下所示。如果log4j 在其他任何地方,您会看到有问题的库以及 v2.5 的编译时声明。
我必须在每个子模块上显式运行它。
$ gradle util:dependencyInsight --dependency org.apache.logging.log4j
Configuration on demand is an incubating feature.
:util:dependencyInsight
org.apache.logging.log4j:log4j-api:2.5
+--- compile
\--- org.apache.logging.log4j:log4j-core:2.5
\--- compile
org.apache.logging.log4j:log4j-core:2.5
\--- compile
(*) - dependencies omitted (listed previously)
BUILD SUCCESSFUL
Total time: 0.933 secs
现在,一旦您知道从哪里排除依赖项,就可以像以前一样删除它。您可以再次运行dependencyInsights 进行确认
dependencies {
// found through `gradle dependencyInsight --dependency org.apache.logging.log4j`
classpath("someOtherGroup:someOtherArtifactId:1.0") {
exclude group: 'org.apache.logging.log4j', module: 'log4j-slf4j-impl'
}
}
另一种解决方案可能是覆盖依赖解析器并将版本强制为2.5
configurations.all {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
if (details.requested.group == "org.apache.logging.log4j") {
println "Updating version for: $details.requested.group:$details.requested.name:$details.requested.version --> 2.5"
details.useVersion '2.5'
}
}
}
我的意见是,我可能不想一直在resolutionStrategy 中添加检查,所以最好在dependencyInsights 中跟踪它。这也意味着在两个地方更新版本,如果另一个开发人员不知道 gradle 的 resolutionStrategy 是如何工作的,那么他们将有“奇怪”的行为......例如。我将log4j 更新为2.7,但它仍然与2.5 一起构建?!?!
但两者都是有效的方法