【问题标题】:Resolve duplicate versions of dependency解决重复版本的依赖项
【发布时间】:2017-01-17 14:56:47
【问题描述】:

这很烦人。我有 2 个项目,项目 ABB 依赖于 A 作为 JAR 文件。所以A中的第三个库X依赖于另一个第三方库Y,问题是maven将项目A中的Y解析为一个版本,但在项目B中解析为另一个版本,比如以下:

commons-beanutils:jar:1.9.2 vs. commons-beanutils:jar:1.8.0

并且下面的版本在项目A中指定:

net.sf.json-lib:json-lib:jar:jdk15:2.4

在项目B的POM.xml中,实际上并没有任何明确指定的依赖版本。

在项目A

[INFO] +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile
[INFO] |  +- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] |  +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] |  \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile

在项目B 中,由于A,只引入了对Y 的依赖:

[INFO] +- A.jar
[INFO] |  +- net.sf.json-lib:json-lib:jar:jdk15:2.4:compile
[INFO] |  |  +- commons-beanutils:commons-beanutils:jar:1.8.0:compile
[INFO] |  |  +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] |  |  \- net.sf.ezmorph:ezmorph:jar:1.0.6:compile

理想的解决方案是只在项目B 中更改pom.xml 以解决重复版本依赖地狱。任何想法?谢谢!

是否可以让项目B 继承A.jar 的依赖项而不是引入自己的依赖项。

编辑

最后我发现了一些有用的东西,所以我把它放在这里以防以后有人可能会遇到同样的问题。

关键是将项目A附带的依赖项放入排除项中,因此maven不会只使用项目A中定义的库版本,而是根据当前上下文计算出一个版本。下面是例子:

<dependency>
    <groupId>com.wonderland</groupId>
    <artifactId>project-a</artifactId>
    <version>1.0</version>
    <exclusions>
        <exclusion>
            <groupId>commons-beanutils</groupId>
            <artifactId>commons-beanutils</artifactId>
        </exclusion>
        <!-- ... everything else to be excluded -->
    <exclusions>
</dependency>

【问题讨论】:

  • 有什么问题? Maven 似乎在这里按预期行事,即通过使用 POM 中声明的版本来解决冲突。
  • 问题是两个版本的依赖最终都在战争中。我知道这两个项目可以共享一个 BOM 来解决差异,但不幸的是,这不是一个选项。
  • 哪场战争?它的 POM 是什么?在WEB-INF/lib 中不能有重复项。
  • 能否请您显示整个依赖关系树?在后台必须有某种依赖调解。 commons-beanutils 可能也在其他一些(传递)点被引用。
  • 感谢您的建议。整个 POM.xml 很长。在上面添加了更多信息以显示上下文。

标签: java maven duplicates dependencies


【解决方案1】:

让我把重点放在一个答案中。

B是war,依赖于jar包A。所以它继承了A的所有传递依赖。

net.sf.json-lib:json-lib:jar:jdk15:2.4:compile 实际上依赖于commons-beanutils:commons-beanutils:jar:1.8.0:compile(我查过了)。所以你的项目 B 正确地解决了这种依赖关系(并将其投入战争)。

项目 A 的树显示了 commons-beanutils 对版本 1.9.2 的依赖。这个版本号一定来自项目 A 中的其他地方。它可能是一个依赖管理,也可能是其他一些依赖。追踪 1.9.2 版本的来源,您就会了解更多。

在任何情况下,war 将仅包含版本 1.8.0 而不是 1.9.2,因为您永远不能在一场战争中拥有两个具有相同 groupId/artifactId 的工件。

【讨论】:

  • 感谢您的总结。问题是战争确实包含同一个库的两个版本,并且包含多个库。
  • @KevinWang 我打赌反对。请给我一个详细的例子,说明两个具有相同 groupId/artifactId 的工件最终在战争中结束。
  • 好的,我给你一个(unzip -l B.war):69409 12-08-2016 14:38 WEB-INF/lib/activation-1.1.1.jar 62983 01-17- 2017 17:36 WEB-INF/lib/activation-1.1.jar
  • 而且他们都有 groupId javax.activation?
  • 您确定在构建之前进行了清理吗? (例如“全新安装”)
猜你喜欢
  • 2014-10-20
  • 1970-01-01
  • 1970-01-01
  • 2015-06-24
  • 2013-01-24
  • 2012-01-21
  • 2021-01-06
  • 2018-11-29
  • 2010-09-30
相关资源
最近更新 更多