CODEWITHSUNDEEP
javamavenduplicatesdependencies
Kevin Wang
Kevin Wang

Reputation: 182

Resolve duplicate versions of dependency

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>

Upvotes: 1

Views: 2588

Answers (1)

J Fabian Meier
J Fabian Meier

Reputation: 35785

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.

Upvotes: 1

Related Questions