Concrete should not depend on specific SLF4J backends

[reckart]

Concrete should not depend on specific SLF4J backends. As a library, concrete should only depend on the SLF4J API, but not on any specific implementations such as LOG4J. The actual backend should be chosen by the user of the the library, i.e. the person that builds an application using concrete.

Having a re-usable library depend on a SLF4J backends introduces a high risk of ending up with multiple backends on the classpath when the library is being used within an application.

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/.../.m2/repository-ukp/org/apache/logging/log4j/log4j-slf4j-impl/2.5/log4j-slf4j-impl-2.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../.m2/repository-ukp/org/slf4j/slf4j-log4j12/1.7.21/slf4j-log4j12-1.7.21.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]

Concretely affected (sorry!) are

• concrete-safe 4.10.0
• concrete-util 4.10.0
• maybe others ;)

[maxthomas]

I've moved the scopes of the log4j dependencies to runtime.

They cannot be removed as these modules contain main methods, so users will expect a logging implementation.

Let me know if this is satisfactory

[reckart]

Frameworks such as SLF4J expect that users provide a dependency on an implementation. The dependencies should be completely removed. Even if you move them to scope "runtime", the high risk of a clash remains - the problem occurs only at runtime anway.

[reckart]

I guess the best would be to move the main methods to another module which would not be used as a library - maybe like concrete-cli.

[maxthomas]

I agree that'd be the best solution, but it's not super realistic at present.

edit: nevermind, you're right. for some reason i thought the runtime scope was not transitive, but indeed it is.

[reckart]

Whether or not a runtime-scoped dependency gets included into a fat jar depends on how you configure your build process.

If I read the documentation correctly, it says that scopes compile and runtime are transitive/inherited (see table).

So a "normal" Maven project that depends on the respective libraries, let's say one that I run in Eclipse or where I run JUnit tests with Maven on the command line should still inherit those runtime dependencies and cause the problem mentioned above.

To check, I created to mini Maven projects test1 and test2. I add commons-io as a runtime dependency to test1. When I now add test1 as a compile dependency to test2, then commons-io also becomes a runtime dependency of test2.

[reckart]

I have tried with 4.12.0 now. In that version log4j-slf4j-impl is a runtime dependency (did you actually do a new release while we were talking?!). However, when I run the unit tests of a project where I have concrete-util as a dependency, I still get the SLF4J warning about multiple dependencies.

[vandurme]

(sorry for delay)

There was internal conversation on this, leading to the agreement along the lines of your -cli comment, that the underlying issue is whether to do a refactor and get all the main methods consolidated. While there is agreement on that being the issue, there isn't agreement on that being worthwhile.