Detecting incompatible dependencies in Maven?

Question

Assume you have set of web apps that use various versions of a common library like Spring. I have a business logic library that also uses this common library. So far no problem, but along the way a version of the common library changed an abstract class definition and broke the business logic library.

So I end up with a compatible version table that looks like this...

business-lib-version | common-lib-version
         1.0         |        1.0
         1.1         |        2.0 

I don't want the business lib version to drive the common lib version in the consuming application. Rather I would like to pick the correct version of the business lib based on the common lib. I'm pretty sure that's not possible so I move on to the main question.

Is there an elegant way to detect version incompatibilities? Ideally I would like a build time solution, otherwise an early run-time solution would be ok.

I've tried using version ranges in Maven but this has caused us many problems due to how Maven sorts versions in non-standard version formats and we also had various issues in resolving ranges correctly at build time.

Answer 1

The Ning dependency-versions-check Maven plugin will fail your build if a dependency version has accidentally been held back by another dependency. It won't fix it for you, but it'll at least tell you!

Answer 2

Is there an elegant way to detect version incompatibilities? Ideally I would like a build time solution, otherwise an early run-time solution would be ok.

I don't know of any way to do this well -- either at runtime or even at build time. There is no standard mechanism for determining the version of packages without investigating the manifests or the jar file names -- which would be a hack at best. Maybe there is a maven plugin that I don't know about that does this automagically but I don't know of one.

We just fix the versions of what libraries we need for our code and upgrade when we need to either because we need additional functionality or another dependency does. Typically we are ahead of other dependencies so we put a typical exclusion marker in our dependency definitions in the pom.xml :

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring</artifactId>
    <version>${spring-version}</version>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>

This allows us to depend on a later version of commons-logging .

If, however, you are using 1.0 of a library but one of your dependencies is using 2.0 then you will have to try the exclusion and see if the dependency runs with 1.0 -- or even compiles. If not then you will be forced to either upgrade your code to work with 2.0 or downgrade the dependency.

Sorry that I couldn't be more help.