SBT 可以用不同的库覆盖传递依赖吗？答案

【问题标题】：Can SBT override a transitive dependency with a different library?SBT 可以用不同的库覆盖传递依赖吗？
【发布时间】：2020-11-26 01:56:40
【问题描述】：

具体用例是关于依赖于旧 log4j 1.x 的第三方库，例如几年前 EOL 的 log4j:log4j:1.2.17。 Apache 提供了更新的 log4j 2.x 库，例如 org.apache.logging.log4j:log4j-1.2-api:2.13.3。我知道我可以使用 excludeDependencies 省略 log4j:log4j 或 dependencyOverrides 来更改依赖项的版本。由于提供了org.apache.logging.log4j:log4j-1.2-api:2.13.3 来实现log4j 1.x API，我希望我可以写一个“喜欢”的规则：

SBT：如果找到log4j:log4j:1.2.17 的传递依赖项，则引入org.apache.logging.log4j:log4j-1.2-api:2.13.3

【问题讨论】：

标签： sbt dependency-management

【解决方案1】：

从技术上讲，您可以通过多种方式做到这一点。例如，您可以添加到您的 sbt：

libraryDependencies ++= Seq(
  "org.apache" %% "dependecy-name" % "version" exclude("org.slf4j","slf4j-log4j12")
  "org.slf4j" %% "slf4j-log4j12" % "other-version"
)

此行将告诉 SBT 不要添加 slf4j-log4j12，因为它是 dependecy-name 所要求的，稍后它将在 other-version 中获取。

话虽如此，我们需要了解这样做的风险。通常，当库添加依赖项时，它会在某个版本中使用其功能。当您决定覆盖该依赖项的版本时，您的代码可能无法编译，或者更糟糕的是，它会运行并导致与您期望的结果不同的结果。如果您确定这两个版本具有相同的功能，您可以这样做。

更新：为了消除依赖，您可以添加到您的build.sbt：

libraryDependencies ~= { _ map {
  case m if m.organization.contains("org") =>
    m.exclude("log4j", "log4j")
  case f => f
}}

这将遍历您的所有依赖项，并且在其组织中包含org 的每个依赖项都将排除 log4j。请注意，这只会在您的libraryDependencies 中的顶级依赖项上生效。

【讨论】：

感谢您的想法。我可能遗漏了一些东西，或者您可能遗漏了问题的细微差别。关键部分是找到一种有条件地排除/包含的方法。对于您提出风险的下半年，这将与问题的另一个细微差别有关。我的特定应用程序是用于生命周期结束的 Log4j 1.x，它被用于 1.x 功能的 Log4j 2.x 适配器取代。所以这是一种特殊情况，其中兼容性对于此覆盖是隐含的。想法或想法？
不错的更新。我从中吸取了教训。我还没有到。在我的实验中，它似乎过滤了直接依赖项而不是传递依赖项。我给定的用例是一个传递依赖，它依赖于已弃用的 log4j 1.x API。我要补充一点，我的 sbt 项目有很多模块，我希望设置一个规则，在某些深度传递依赖试图引入 1.x jar 的情况下排除/替换。我目前正在做的是从 all 模块中排除 1.x 并将 2.x shim 导入所有模块，无论它们是否需要。
这正是我所说的。它适用于直接依赖项。但是，如果您在直接依赖项上调用 m.exclude("log4j", "log4j")，它将无法获取它。您可以通过编辑我添加的if 语句来控制哪些模块应该应用该逻辑。在我的实验中，添加此更改后，log4j:log4j 不在我正在处理的依赖树中。
另外，为什么要从传递依赖中排除依赖？假设您有一个依赖项a，它依赖于b 和c。您只想从b 中排除依赖关系d？您可以从c 取回它。我在这里想念什么？如果要排除它，则要全局排除它。我认为您需要将其置于条件下的唯一原因是在不同的 scala 版本上使用不同的依赖项。
我正在寻找的更像是，“如果 A 是任何深度的传递依赖项，则排除 A 并包含 B。”我越来越相信这是不可能的。我希望其他人有一个好主意。