Nathan at Work

When deploying applications using apache maven you often run in to dependency issues, two conflicting jars and the wrong one being used.

I recently ran in to this one when trying to deploy a multi-project application we are building at kraya; basically hibernate and cxf both depend on slf4j-* jars; hibernate down in the domain model project was depending on a newer version and using the method org.slf4j.impl.JDK14LoggerAdapter.trace, however the final web app depended on apache cxf which used an older version 1.3.1 of slf4j, which didn’t have the trace method.

Ultimately this led to an exception when deploying, “java.lang.AbstractMethodError: org.slf4j.impl.JDK14LoggerAdapter.trace”

To fix was a case of going through the dependency hierarchy in the web apps pom, locating the conflict on slf4j then changing the pom’s to make everything depend on the newer version.

from the maven site:

Dependency mediation – this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the “nearest definition” which means that it will use the version of the closest dependency to your project in the tree of dependencies.

Translated this means the higher a dependency is in the dependencies block of the pom, the more weight it is given. In our case the resolution was to move the DomainModel project (with the newer hibernate slf4j jar) to the top of the dependencies. This fixed one of the two conflicts, namely slf4j-api.

Next up was to go to the pom of another dependent project (in the pom above cxf) and add in the dependency for the latest 1.5.6 same 1.5.2 version of slf4j-jdk14 as hibernate.

Job done, and no old 1.3.1 slf4j get deployed; thus no exception.

joy, and simpler than I though.