How to check maven dependency compatibility

Question

I'm trying to figure out if it is possible to check whether a maven dependency is still compatible in the configured configuration of a project.

Here is my Test setup:

There are 3 projects. Child-A, Child-B, Child-C.

Child-A is available in 2 Version which are not compatible to each other. Version 0.0.1-SNAPSHOT has a method

public void myMethod(String oneParameter)

Version 0.0.2-SNAPSHOT changes this method to

public void myMethod(String oneParameter, String secondParameter)

Child-B has a dependency to Child-A in Version 0.0.1-SNAPSHOT and calls the method with one parameter.

public class ChildB {
    public void callChild(String myParam) {
        final ChildA test = new ChildA();
        String methodParam = String.format("%s is calling %s with Parameter %s ", this.getClass().getName(),
                test.getClass().getName(), myParam);
        test.myMethod(methodParam);
    }
}

Child-C now has a dependency to Child-B and a dependency to Child-A Version 0.0.2-SNAPSHOT.

Child-C calls Child-B in this way:

public static void main(String[] args) {
    ChildB inner = new ChildB();
    inner.callChild(" Parameter from main method! ");
}

For the compiler this is just fine, but during runtime Child-B will run into trouble because Child-A is present in Version 0.0.2-SNAPSHOT and therefore the method with just one Parameter does not exist anymore.

I'm trying to configure my maven setup in that way that when Child-C is build it will check the signatures / compatibility of its dependencies with the setup of it's effective pom.

I thought the maven animal-sniffer plugin could be a solution, but didn't found a section to check inner dependencies.

Does anybody know how to check those behavior?

Does nobody has any idea how to go on with this challenge. – Matze Aug 17 '16 at 06:34 — Matze, Aug 17 '16 at 06:34

score 1 · Answer 1 · answered Jul 20 '17 at 09:33

1

The problem is not with Maven. Even if both versions are present at runtime, only one will be loaded by the JVM so you will get a runtime exception due to one or the other method being missing.

The best solution is to add the single parameter method to version 0.0.2 and specify that version in all poms. If that does not work you will need to modify your code so only the two-parameter method is called.

answered Jul 20 '17 at 09:33

kiwiron

1,677
11
17

Thank you for your answer. I have multiple dependencies in my project and some of them have dependencies to an artifact but with different versions. Therefore I wanted to check the compatibility to see if my dependencies will run into trouble... (during runtime!). – Matze Jul 20 '17 at 10:24

score 1 · Answer 2 · answered Dec 13 '18 at 08:39

You can use the maven enforcer to reach dependency convergence.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

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

This will show you the dependency convergence issues like this:

  Dependency convergence error for org.codehaus.jackson:jackson-jaxrs:1.7.1 paths to dependency are:
+-com.nodeable:server:1.0-SNAPSHOT
  +-org.mule.modules:mule-module-jersey:3.2.1
    +-com.sun.jersey:jersey-json:1.6
      +-org.codehaus.jackson:jackson-jaxrs:1.7.1
and
+-com.nodeable:server:1.0-SNAPSHOT
  +-org.mule.modules:mule-module-jersey:3.2.1
    +-org.codehaus.jackson:jackson-jaxrs:1.8.0

This way you can make sure you don't have multiple versions of the same library as a dependency, and eliminate the possibility of classloading issues.

If the signature of the method you mentioned changed, you should be able to see the errors on compile time anyway.

is it a good practice to do this? If for example the pom.xml will reach a long lenght due to exclusions because of that is it better than having it shorter, without exclusions but have many dependencies "omitted due to duplicate" ? Thank you! — Oana-Elena Danescu, Apr 05 '22 at 09:47

How to check maven dependency compatibility

2 Answers2