依赖管理的传递效应

Posted

技术标签:

【中文标题】依赖管理的传递效应【英文标题】:Transitive effect of dependencyManagement 【发布时间】:2016-12-13 23:20:45 【问题描述】:

在 Maven 中,您可以通过 dependencyManagement 中的条目覆盖传递依赖的版本号,因为 dependencyManagement 优先于传递依赖定义。

但是(传递)依赖项的 poms 中的dependencyManagement 定义呢?他们有考虑吗?如果是这样,它们覆盖了什么,它们是如何覆盖的?

【问题讨论】:

【参考方案1】:

传递依赖项的 pom 中的dependencyManagement 定义被考虑,只要它们没有在您的项目的dependencyManagement 或更接近的依赖项(在依赖项树中)中被覆盖。

换句话说,

依赖中介:规则很简单

“最近的定义”,这意味着它将使用依赖关系树中与您的项目最接近的依赖关系的版本。

如果两个依赖版本在依赖树中的深度相同,则第一个声明获胜(声明顺序)。

更多详情见Transitive Dependency

希望这会有所帮助。

【讨论】:

谢谢。您的链接是否解释了传递依赖管理的规则或仅用于依赖关系?很高兴在第一段中看到您声明的来源。 它是关于传递依赖的 所以你的意思是,你不知道传递依赖管理的来源(你在第一段中所说的)? 你检查链接了吗? 我检查了链接。也许我是个盲人,但你能告诉我我在哪里找到你的陈述的来源吗?【参考方案2】:

依赖管理隐含是可传递的。不需要为此制定特殊规则,而是已经提到的规则的结果:Transitive Dependencies。

考虑这个示例结构:

您的模块 A - 依赖 D - 传递依赖 B - 依赖 D - 传递依赖

AB 构建时,如果没有明确指定,则会检查它们对应的dependencyManagement 部分以选择D 的版本。 这是重要的部分:AB 用作依赖项以确定它们所依赖的D 的哪个版本时,使用完全相同的过程。因此,它们不会以任何方式相互影响。

这可能会导致,例如,A 取决于 D:1.0B 取决于 D:1.1,此时它们的 dependencyManagement 部分已被应用以确定这一点并且不会被采用不再考虑。使用此信息作为输入,依赖中介规则将被应用于为您的模块选择一个版本的 D

链接页面中还描述了依赖关系调解规则。但简而言之,最接近的定义获胜,并根据顺序打破平局。自然,模块本身中的定义总是最接近的。

现在假设您的模块被用作依赖项。由于dependencyManagement 部分中的定义,您的项目可能基于上述所有规则依赖于D:1.2,但这就是dependencyManagement 的范围结束的地方。

(请注意,import 范围是一个例外,因为它的行为与其他范围完全不同。)

【讨论】:

谢谢。您的声明是否有其他来源(文档、源代码等)? @JFMeier,您认为我的哪一部分解释与链接的文档页面不对应,因此需要其他来源? "当A或B被用作依赖来确定D的哪个版本时使用完全相同的过程"你从哪里得到这个? 请仔细阅读链接的传递依赖部分,它包含您需要的一切。例如,“通过从指定的远程存储库中读取依赖项的项目文件来促进此功能。” 我认为您的描述很可能是正确的,但我在传递依赖项部分没有找到它。我没有看到任何明确说明该机制如何工作的句子或段落。

以上是关于依赖管理的传递效应的主要内容,如果未能解决你的问题,请参考以下文章

Maven 依赖管理版本在传递依赖中被忽略

Maven 依赖管理版本在传递依赖中被忽略

Android Gradle 插件Gradle 依赖管理 ⑦ ( dependencies 传递依赖设置 | transitive 关闭依赖传递配置 | exclude 排除子依赖配置 )

Maven 依赖管理 -- 依赖配置 & 依赖传递 (概念 & 依赖传递冲突问题 & 可选依赖(不透明) & 排除依赖(不需要))

Gradle-5.3:依赖-管理依赖的版本(传递(transitive)排除(exclude)强制(force)动态版本(+))

04_项目一众筹00_05Maven依赖概念,依赖范围依赖传递性依赖的原则:解决jar包冲突依赖排除统一版本管理