43

我使用 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上面的例子有点奇怪。

4

2 回答 2

66

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

一个简单的案例：

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

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

请注意，这只是对您的情况的简化。看到这个依赖树，你会排除 projectA 给出的依赖 projectB ：

<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 也已将其依赖项 projectB 升级到版本 5.0 ：

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

在这种情况下，您刚才所做的排除将排除 projectB 5.0 版。

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

解决方案是什么？

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

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

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

事实上，排除依赖项并没有什么坏处。但是每次更新已设置排除项的依赖项时，您必须检查：

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

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

于 2013-04-26T14:58:32.307 回答
3

如果作为工件的 JUnit 作为编译范围内的依赖项通过，则这是您的库之一的错误，此处为：ca.juliusdavies。

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

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

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

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

于 2013-04-22T14:46:29.000 回答