3

我正在使用 maven enforcer 插件，但我发现了这种依赖收敛的奇怪案例：

Dependency convergence error for commons-collections:commons-collections:3.2.1 paths to dependency are:
+-ProjectA:B:0.1
  +-commons-validator:commons-validator:1.6
    +-commons-beanutils:commons-beanutils:1.9.2
      +-commons-collections:commons-collections:3.2.1
and
+-ProjectA:B:0.1
  +-commons-validator:commons-validator:1.6
    +-commons-collections:commons-collections:3.2.2

这是依赖声明：

<dependency>
    <groupId>commons-validator</groupId>
    <artifactId>commons-validator</artifactId>
    <version>1.6</version>
</dependency>

您可以看到相同的工件使用相同依赖项的不同版本。这怎么可能发生？抑制警告的唯一方法是在我的 pom.xml 中包含该依赖项的最新版本作为直接依赖项。

我错过了什么吗？

4

2 回答 2

2

从依赖关系树中，您可以看到commons-validator:commons-validator:1.6直接依赖于commons-collections:commons-collections:3.2.2，但也具有传递依赖于commons-collections:commons-collections:3.2.1. 这没有什么不寻常的。

要解决此问题，您需要选择一个版本。只需遵循 khmarbaise 的建议并在<dependencyManagement>您的 POM 部分添加一个条目。

于 2019-10-26T08:49:33.560 回答
1

最重要的是，相同的工件不使用相同依赖项的不同版本。

+-ProjectA:B:0.1
  +-commons-validator:commons-validator:1.6
    +-commons-beanutils:commons-beanutils:1.9.2
      +-commons-collections:commons-collections:3.2.1
and
+-ProjectA:B:0.1
  +-commons-validator:commons-validator:1.6
    +-commons-collections:commons-collections:3.2.2

依赖关系直接和传递commons-validator:commons-validator:1.6使用（其他依赖关系的依赖关系）。Maven 的依赖调解将基于最近的原则解决这个冲突。看看这些： [1]依赖机制 [2]依赖调解和冲突解决commons-collections:commons-collections:3.2.2commons-collections:commons-collections:3.2.1

maven-enforcer-plugin 的dependencyConvergence 规则工作正常。正如文档所说：

此规则要求依赖版本号收敛。如果一个项目有两个依赖项 A 和 B，它们都依赖于同一个工件 C，如果 A 依赖于不同版本的 C，则此规则将导致构建失败，然后 C 的版本依赖于 B。

因为 commons-validator (A) 和 commons-beanutils (B) 取决于 commons-collections (C) 并且这些依赖项具有不同的版本，所以这种行为是完全合理的。

你决定你到底想做什么。

继续使用dependencyConvergence 规则并解决此错误

在这种情况下，只需定义commons-collections, commons-loggingand部分并将这些依赖项作为托管依赖项放在您的项目中。commons-validator<dependencyManagement>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>commons-validator</groupId>
                <artifactId>commons-validator</artifactId>
                <version>1.6</version>
            </dependency>
            <dependency>
                <groupId>commons-collections</groupId>
                <artifactId>commons-collections</artifactId>
                <version>3.2.2</version>
            </dependency>
            <dependency>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
                <version>1.2</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>commons-validator</groupId>
            <artifactId>commons-validator</artifactId>
        </dependency>
        <dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
        </dependency>
        <dependency>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </dependency>
    </dependencies>

我认为它需要大量的过度工作，一段时间后您的项目模型将无法维护。另一方面，Dependency Mediation规则解决了这个问题。

使用其他规则，例如 requireUpperBoundDeps

此规则旨在调查构建期间已解决的依赖项是否低于所有传递依赖项声明。例如，如果您的项目依赖commons-collections:3.0但commons-validator需要更新版本，它将失败commons-collections:3.2.2

    <dependencies>
        <dependency>
            <groupId>commons-validator</groupId>
            <artifactId>commons-validator</artifactId>
            <version>1.6</version>
        </dependency>
        <dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
            <version>3.0</version>
        </dependency>
    </dependencies>

忘记执行者和信任依赖中介

几乎所有情况下，这是正确的决定，因为Dependency Mediation它工作正常。

于 2019-10-26T10:42:40.243 回答