Solving a jar hell with maven?

Question

I'm using two jars A and B. B is a library and A has classes that uses some old classes from library B. Now this is causing me a problem when I include both jars in my project classpath as there are the same names of two classes but one of them is older than the other and behave differently.

One solution to this problem I found is by first importing library B into Eclipse and then I click OK and the project builds. Then I add the jar A. This way all my existing code will use the newer versions of B and the classes of A will be untouched.

However now I want to use Maven for my projects but I'm unable to know how to make this trick again using Maven. Please help.

There is no `jar hell` with maven :) But your old configuration stinks like `jar hell` solution. — MariuszS, Jan 14 '14 at 08:34
@MariuszS Maybe you got me wrong. The previous solution was done before using maven. Now I learned maven and I want to apply the same trick but using maven. — Jack Twain, Jan 14 '14 at 08:42
I think this is impossible, simply make cleanup with jar A and B. — MariuszS, Jan 14 '14 at 08:50
@user2310289 I would argue that it's not nicer, just a different circle. — Brian Roach, Jan 14 '14 at 09:39

score 4 · Answer 1 · edited Jan 14 '14 at 09:41

Maybe you can solve your problem by renaming the package of the class that you don't want.

You can do it by using Maven Shade Plugin

This plugin allows to rename package names at compilation.

Usage :

   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
        <execution>
        <phase>package</phase>
        <goals>
            <goal>shade</goal>
            </goals>
        <configuration>
                <relocations>
                    <relocation>
                            <pattern>com.example.package.name.YourClass</pattern>
                               <shadedPattern>com.example.rename.package.name.YourClass</shadedPattern>
                    </relocation>
                </relocations>
                    <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
        </configuration>
        </execution>
    </executions>
</plugin>

score 3 · Answer 2 · answered Jan 14 '14 at 09:02

This isn't necessarily a Maven problem. The default classloader will search for classes according to the order of the jars on the classpath. When you are adding the jars to Eclipse you are doing so in a way that their order will ensure the correct classes are loaded - specifically B appears on the classpath before A and therefore, when the same class is in both jars, it will be loaded from B.

Since version 2.0.9 of Maven, the classpath is built according to the order of the dependencies in the POM. So, providing dependency B is declared before the dependency A, you should get the same behaviour are with Eclipse.

Needless to say, relying on classpath order in this way is rather fragile and personally I'd look to clean-up the jars if that's possible.

Then make sure that there's very clear comments in the pom indicating that the order of the dependencies is important, just in case somebody feels like having a tidy-up and re-orders them in the process. — Nick Holt, Jan 18 '14 at 16:21

score 0 · Answer 3 · answered Jan 14 '14 at 08:45

The problem is very real (unless for me). If you have detected what libraries are the conflicted, you can use exclusions to prevent import libraries that you dont want. If you dont know what are the conflicted libraries, in eclipse using the default maven plugin you can open the pom file and select the tab "Dependency Hierarchy" in the right column you can see all your resolved dependencies for your project, and in the left what library import each dependency.

I hope it can help you.

This is about classes conflict, not dependency conflict. Eclipse dosent read dependencies from jar. — MariuszS, Jan 14 '14 at 08:51

Solving a jar hell with maven?

3 Answers3

Linked