views:

379

answers:

1

I have a maven project A that use hibernate-annotations 3.4.0.GA which use the slf4j-api version 1.5.5 (checked through the dependency tree in the pom.xml file). Further project A specifies slf4j-log4j12 version 1.4.2 as a dependency.

I have another maven project B which depend on project A. In project B I have specified the following dependencies:

slf4j-api version 1.6.1,
logback-core version 0.9.24
logback-classic version 0.9.24

which builds fine with maven from the command line. But when I run the project from eclipse launch configuration I get:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/C:/Users/mm/.m2/repository/org/slf4j/slf4j-log4j12/1.4.2/slf4j-log4j12-1.4.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/C:/Users/mm/.m2/repository/ch/qos/logback/logback-classic/0.9.24/logback-classic-0.9.24.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: slf4j-api 1.6.x (or later) is incompatible with this binding.
SLF4J: Your binding is version 1.5.5 or earlier.
SLF4J: Upgrade your binding to version 1.6.x. or 2.0.x

From this message its indicated to that I need to upgrade the binding in project A to 1.6.x, but I don't see how that is possible since its included in the hibernate dependency.

Is it possible to switch the binding (updating the classpath info) when running project B so it use the 1.6.1 version instead of the version from the hibernate project?

+3  A: 

I have a maven project A that use hibernate-annotations 3.4.0.GA which use the slf4j-api version 1.5.5 (checked through the dependency tree in the pom.xml file). Further project A specifies slf4j-log4j12 version 1.4.2 as a dependency.

That's not recommended, you should use the same versions of slf4j artifacts. From the FAQ:

Are SLF4J versions backward compatible?

With rare theoretical exceptions, SLF4J versions are backward compatible. This means than you can upgrade from SLF4J version 1.0 to any later version without problems.

However, while the SLF4J API is very stable from the client's perspective, SLF4J bindings such as slf4j-simple or slf4j-log4j12 may require a specific version of slf4j-api. Mixing different versions of slf4j artifacts can be problematic and is strongly discouraged. For instance, if you are using slf4j-api-1.5.6.jar, then you should also use slf4j-simple-1.5.6.jar, using slf4j-simple-1.4.2.jar will not work.

At initialization time, if SLF4J suspects that there may be a version mismatch problem, it emits a warning about the said mismatch. For the exact details of the version mismatch detection mechanism, please refer to the relevant entry in this FAQ.

That's something to fix.

which builds fine with maven from the command line. But when I run the project from eclipse launch configuration I get (...)

The problem is that you get the SLF4J artifacts from B and those from A (transitively) and you thus end up mixing several versions of the slf4j-api (1.5.5 and 1.6.1) and several bindings (slf4j-log4j12 and logback-classic). SLF4J is complaining about the later problem at runtime but you should fix both.

From this message its indicated to that I need to upgrade the binding in project A to 1.6.x, but I don't see how that is possible since its included in the hibernate dependency.

Yes, the message suggests upgrading a binding to a more recent version. But, more important, it reports that you have more than ONE binding on the class path: you need to choose between log4j and logback as logging backed and to provide the appropriate binding, but not both of them.

Is it possible to switch the binding (updating the classpath info) when running project B so it use the 1.6.1 version instead of the version from the hibernate project?

To strictly answer this question about controlling versions in transitive dependencies, this can be done using the dependencyManagement element. Here is an example:

<project>
  ...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.6.1</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  ...
  <dependencies>
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-entitymanager</artifactId>
      <version>3.4.0.GA</version>
    </dependency>
  </dependencies>
  ...
</project>

And artifacts having slf4j-api as dependency, such as Hibernate EntityManager, would use version 1.6.1 as shown below:

$ mvn dependency:tree
...
[INFO] +- org.hibernate:hibernate-entitymanager:jar:3.4.0.GA:compile
[INFO] |  +- org.hibernate:ejb3-persistence:jar:1.0.2.GA:compile
[INFO] |  +- org.hibernate:hibernate-commons-annotations:jar:3.1.0.GA:compile
[INFO] |  +- org.hibernate:hibernate-annotations:jar:3.4.0.GA:compile
[INFO] |  +- org.hibernate:hibernate-core:jar:3.3.0.SP1:compile
[INFO] |  |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  |  \- commons-collections:commons-collections:jar:3.1:compile
[INFO] |  +- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] |  +- dom4j:dom4j:jar:1.6.1:compile
[INFO] |  |  \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  +- javax.transaction:jta:jar:1.1:compile
[INFO] |  \- javassist:javassist:jar:3.4.GA:compile

But as I said, the real problem is that you need to have only one binding on the classpath. Either choose log4j or logback, just not both, and provide the appropriate binding.

Pascal Thivent
I did run mvn dependency:tree on project A which has a dependency on hibernate. And it shows that hibernate-annotations version 3.4.0.GA use the slf4j-api version 1.5.5 and not 1.6.1.If I understand you correctly all projects depending on module A should use the same version as hibernate - 1.5.5?Seems rather fragile to me that all projects which depend on each other must use the same version. Further I cannot use slf4j 1.6.1 before hibernate updates to that version.
tul
@tul: Yes, all projects should use the same version. No, they don't have to use the same version as Hibernate. As I told you, you can control the versions of artifacts in transitive dependencies using the `dependencyManagement` element and I provided an example. There is no need to wait for Hibernate to update the version they use. Just use the `dependencyManagement` element, that's the way to go.
Pascal Thivent
@Pascal Thivent +1 for the FAQ link
Arthur Ronald F D Garcia