解决 Maven 依赖性收敛问题

java maven dependency-management maven-enforcer-plugin

2022-09-01 00:59:29

我使用maven-enforcer-plugin来检查依赖性收敛问题。典型的输出为：

[WARNING] Rule 1: org.apache.maven.plugins.enforcer.DependencyConvergence failed 
  with message:
Failed while enforcing releasability the error(s) are [
Dependency convergence error for junit:junit:3.8.1 paths to dependency are:
+-foo:bar:1.0-SNAPSHOT
  +-ca.juliusdavies:not-yet-commons-ssl:0.3.9
    +-commons-httpclient:commons-httpclient:3.0
      +-junit:junit:3.8.1
and
+-foo:bar:1.0-SNAPSHOT
  +-junit:junit:4.11
]

看到此消息，我通常会通过排除传递依赖关系来“解决”它，例如

<dependency>
  <groupId>ca.juliusdavies</groupId>
  <artifactId>not-yet-commons-ssl</artifactId>
  <version>0.3.9</version>
  <exclusions>
    <!-- This artifact links to another artifact which stupidly includes 
      junit in compile scope -->
    <exclusion>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </exclusion>
  </exclusions>
</dependency>

我想了解这是否真的是一个修复程序，以及以这种方式排除库所涉及的风险。正如我所看到的：

“修复”通常是安全的，只要我选择使用较新版本。这依赖于库作者保持向后兼容性。
通常对Maven构建没有影响（因为更接近的定义获胜），但是通过排除依赖关系，我告诉Maven我知道这个问题，从而安抚maven-enforcer-plugin。

我的想法是否正确，是否有其他方法来处理此问题？我对专注于一般情况的答案感兴趣 - 我意识到上面的例子有点奇怪。junit

答案 1

我们都同意，JUnit 永远不应该设置为除以外的其他作用域。一般来说，我不认为除了排除不需要的依赖之外还有另一种解决方案，所以我们都同意你这样做是对的。test

一个简单的案例：

正如Andreas Krueger所说，版本可能存在风险（我实际上遇到了它）。假设项目的依赖项如下：

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:2.0
     +-group2:projectB:3.8.1
  +-group2:projectB:4.11

请注意，这只是对您的情况的简化。看到这个依赖关系树，您将排除由项目A给出的依赖关系项目B：

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>2.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

使用 maven 打包项目后，剩余的依赖项将是 group2-someProjectB-4.11.jar 版本 4.11，而不是 3.8.1。一切都会好起来的，项目将运行而不会遇到任何问题。

然后，过了一会儿，假设您决定升级到项目A的下一个版本，版本3.0，它添加了新的强大功能：

<dependency>
  <groupId>group1</groupId>
  <artifactId>projectA</artifactId>
  <version>3.0</version>
  <exclusions>
    <exclusion>
      <groupId>group2</groupId>
      <artifactId>projectB</artifactId>
    </exclusion>
  </exclusions>
</dependency>

问题是您还不知道 projectA 版本 3.0 也已将其依赖项项目 B 升级到版本 5.0：

+-foo:bar:1.0-SNAPSHOT
  +-group1:projectA:3.0
     +-group2:projectB:5.0
  +-group2:projectB:4.11

在这种情况下，您不久前所做的排除将排除 projectB 版本 5.0。

但是，项目 A 版本 3.0 需要项目 B 版本 5.0 的改进。由于排除，在用maven打包项目后，剩余的依赖项将是group2-someProjectB-4.11.jar，版本4.11而不是5.0。在您使用projectA的任何新功能时，程序将无法正常运行。

解决方案是什么？

我在Java-EE项目中遇到了这个问题。

一个团队开发了数据库服务。他们将其打包为项目A。每次更新服务时，他们还更新了一个文件，其中列出了所有当前依赖项和当前版本。

ProjectA是我正在处理的Java-EE项目的依赖项。每次服务团队更新 ProjectA 时，我也会检查版本的更新。

事实上，排除依赖关系没有坏处。但是，每次更新设置了排除项的依赖项时，都必须检查：

如果这种排除仍然有意义。
如果需要在自己的项目中升级已排除依赖项的版本。

我猜maven排除就像菜刀一样。它很锋利，毫不费力地切蔬菜，但在处理时需要小心......

答案 2

如果 JUnit 作为工件在编译范围内作为依赖项出现，那么它就是您的一个库的 bug，如下所示：ca.juliusdavies。

JUnit 应始终包含在测试范围内。因此，在成功构建时，它不会打包到生成的.jar，.war或.ear文件中。

一般来说，排除已经包含的依赖项没有坏处，因为库 1 和库 2 共享一个公共依赖项。

当然，唯一可能发生的问题是，当库 1 和库 2 包含同一依赖工件的不同版本时。当库的功能发生更改时，这可能会导致运行时错误。幸运的是，这种情况并不常见，除非版本号的差异很大。通常，建议包含最新的依赖项版本并排除较旧的依赖项版本。这在大多数情况下是可行的。

如果没有，请检查项目的第一级依赖项是否有更新。