CODEWITHSUNDEEP
javamaven
user2250246
user2250246

Reputation: 3967

Maven: Different library versions in one JVM

I have a project whose dependency tree is huge i.e. it packs in modules from several teams.

Now there are some commonly used dependencies which are common across several modules.

A simplified example can be:

TopModule.jar
  ChildModule.jar
    CommonModule-v1.jar
  CommonModule-v2.jar

When I build my project, I specify the latest version of common dependencies, but its very hard to ask the same from every other team.

So, frequently, the TopModule is built using different versions of CommonModule (v1 and v2 in the above example).

My question is:

If the final jar file contains both CommonModule-v1.jar and CommonModule-v2.jar, how does it affect the runtime?

Can the runtime erroneously load versions v2 where v1 is required and vice versa?

Upvotes: 5

Views: 3994

Answers (6)

MariuszS
MariuszS

Reputation: 31595

To fight with this problem globally use this DependencyConvergence Rule

This rule requires that dependency version numbers converge. If a project has two dependencies, A and B, both depending on the same artifact, C, this rule will fail the build if A depends on a different version of C then the version of C depended on by B.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-enforcer-plugin</artifactId>
    <version>1.3.1</version>
    <executions>
      <execution>
        <id>enforce</id>
        <configuration>
          <rules>
            <DependencyConvergence/>
          </rules>
        </configuration>
        <goals>
          <goal>enforce</goal>
        </goals>
      </execution>
    </executions>
</plugin>

After this all teams work together with consistent versions of dependencies.

Upvotes: 1

Daniel Kaplan
Daniel Kaplan

Reputation: 67494

On top of what @yshavit said, ideally you'd exclude the earlier version of the CommonModule so that only v2 is in the classpath. This is only possible if the CommonModule v2 api is backwards compatible with CommonModule v1.

Here's an example of how you exclude:

    <dependency>
        <groupId>ChildModuleGroupid</groupId>
        <artifactId>ChildModuleArtifactid</artifactId>
        <version>1.0</version>
        <exclusions>
            <exclusion>
                <groupId>CommonModuleGroupId</groupId>
                <artifactId>CommonModuleArtifactId</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

You'd put that in the TopModule pom.xml.

Upvotes: 0

ssedano
ssedano

Reputation: 8432

If your pom.xml is only an aggregator of already packaged modules then this apply. If it is not the case and your project actually compile and packages all of those modules as a submodules then maven will choose one. If it compiles every project on its own then it will be packaged using that dependency. But if all of them end up in the same class loader then it won't work fine.

At runtime it can cause errors, think of method not found and the like. Your byte code classes were compiled and linked with the correct dependencies but since the class loader finds two candidates it just load one at runtime.

What you can do is set a parent pom defining a <dependencyManagement> and then ask all teams to use it as a parent and don't declare <version> but inherit it from the parent pom.xml.

References http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management

Upvotes: 0

Andrey Chaschev
Andrey Chaschev

Reputation: 16526

Classloader will load the first JAR which appears on your classpath. In more details - it will search for the first class on your class path, so in each case all these searches would fall into i.e. CommonModule-v2.jar. So the answer is yes - it can erroneously load versions v2 where v1 if it appears earlier on your classpath.

Upvotes: 0

yshavit
yshavit

Reputation: 43401

Maven will only use one version of each artifact in the end -- it doesn't do any fancy classloader isolation tricks. You can see which version it'll use with mvn dependency:resolve.

If you need to use specific versions within dependencies, you can use the shade plugin. It'll do renaming trickery so that dependencies get their own versions of libraries.

Upvotes: 4

thst
thst

Reputation: 4602

This depends on the way the modules are named in maven. Usually, maven tries to resolve the conflicting libs and takes the highest version into the tree. But if the libraries are different artifacts in terms of artifactId, then maven will not see that they are from the same breed and thus will not resolve the ambiguity.

Usually you resolve this by a common parent.pom, where you define the versions of commonly used libraries throughout the project. If you have no control over the other projects (not part of your build, only dependencies), you may be lucky to have your final project working fine. If the library breaks compatibility in the newer version, you will not be able to use it.

So, does your final project contain both versions of the library or not, did you check it? The dependency tree may show both versions, but if maven will use only the latest version of a dependency in the hierarchy.

Upvotes: 0

Related Questions