解决重复版本的依赖项 [英] Resolve duplicate versions of dependency

问题描述

这很烦人。我有2个项目，项目 A 和 B ， B 依赖 A 作为JAR文件。因此，A中的第三个方库 X 依赖于另一个第三方方库 Y ，问题是maven解析了<$项目 A 中的c $ c> Y 到版本，但是项目 B 中的c $ c> Y 另一个版本，如下所示：

  commons-beanutils：jar：1.9.2与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 只引入对 Y 的依赖，因为 A ：

  [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> 
<！-... ...其他所有要排除的对象-> 
< exclusions> 
< / dependency> 
  

解决方案

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

B是一场战争，并且取决于jarA。因此，它继承了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中的其他位置。它可能是dependencyManagement，也可能是其他依赖关系。跟踪版本1.9.2的来源，您将了解更多。

无论如何，战争将只包含版本1.8.0，而不包含版本1.9.2，因为您一次战争中永远不会有两个具有相同groupId / artifactId的工件。

This has been very annoying. I have 2 projects, project A and B, B with dependency on A as a JAR file. So a 3rd library X in A has a dependency on another 3rd party library Y, the problem is maven resolves Y in project A to a version, but in project B to another version, like the following:

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

And the version below is specified in project A:

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

In the POM.xml of project B, there isn't really any explicitly specified version of dependencies.

In project 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

In project B that only introduces the dependency on Y because of A:

[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

The ideal solution is to only make changes in pom.xml in project B to solve the duplicate versions dependency hell. Any idea? Thanks!

Is it possible to make project B inherit dependencies from A.jar instead of introducing those of its own.

EDIT

In the end I found something that worked, so I'd just put it here in case someone may be facing the same problem later.

The key is to put the dependencies come with project A into exclusions, so maven won't just use the versions of libraries defined in project A, but work out a version based on the current context. Below is the example:

<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>

解决方案

Let me put the main points into an answer.

B is a war and depends on the jar A. So it inherits all the transitive dependencies of A.

net.sf.json-lib:json-lib:jar:jdk15:2.4:compile has actually a dependency on commons-beanutils:commons-beanutils:jar:1.8.0:compile (I looked that up). So your project B correctly resolves this dependency (and puts it into the war).

The tree of project A shows a dependency of commons-beanutils on version 1.9.2. This version number must have come from some other place inside project A. It may be a dependencyManagement, it may be some other dependency. Track down where the version 1.9.2 comes from and you know more.

In any case, the war will only contain the version 1.8.0 and not 1.9.2 as you can never have two artifacts with same groupId/artifactId in one war.

这篇关于解决重复版本的依赖项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！