Simpler way to exlude commons-logging in Spring

[Ceki Gülcü]

Chapter 1 of the Spring documentation, more precisely section 1.3.2.1, describes a strategy of replacing commons-logging with slf4j. The described strategy uses maven exclusions. I think a considerably simpler and more robust strategy is to declare commons-logging in the provided scope. The actual commons-logging classes would be provided by jcl-over-slf4j. This translates into the following pom file snippet:

<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.6.1</version>
</dependency>

The first dependency declaration essentially states that commons-logging will be "somehow" provided by the user's environment. The second declaration includes jcl-over-slf4j into your project. As jcl-over-slf4j is a perfect binary-compatible replacement for commons-logging, the first assertion becomes true.

This approach covers all dependencies using commons-logging with just one declaration whereas with the explicit exclusion approach commons-logging needs to be explicitly excluded in every dependency depending on common-logging.

[sslavic]

If one wants to use single logging API, and slf4j-api to be it, IMO better approach is to have commons-logging excluded from dependencies, and jcl-over-slf4j defined as runtime dependency. As a result compilation of new classes that make use of commons-logging api by mistake will fail.

[Ceki Gülcü]

Declaring commons-logging in the provided scope as described above nicely solves an extremely common problem. In contrast, explicitly excluding common-logging is an error-prone and cumbersome process.

What you are describing seems to address a different problem than the one I am trying to solve.

If one wants to use single logging API, and slf4j-api to be it, IMO better approach is to have commons-logging excluded from dependencies, and jcl-over-slf4j defined as runtime dependency. As a result compilation of new classes that make use of commons-logging api by mistake will fail.

[jecki]

Hi Ceki. sslavic has a point here. But then you are right that it is simpler to set the scope of commons-logging to provided, rather than having to add exclusion in all library that has dependency on commons-logging.

BTW, how come you are a junior here in spring forum. You are the famous Ceki Gülcü

[sslavic]

Yes, there's a choice here between being efficient and effective.

[Ceki Gülcü]

Yes, there's a choice here between being efficient and effective.

Spring-core will probably continue to use commons-logging as its logging API. As far as I know, spring-core has not expressed an intention to use SLF4J as a logging API. So, my proposal address an existing problem not a hypothetical one.