Sven Haster opened SPR-16062 and commented
spring-jcl has duplicated a number of classes from apache commons logging, such as org.apache.commons.logging.Log spring-core has a dependency on spring-jcl and therefore everyone who has a dependency on spring-core gets these duplicate classes and has errors resulting from this if they also depend on commons logging or slf4j-jcl
This is less than ideal and goes against convention. It would be better to either a) have a dependency on commons-logging or b) if you really want to include these classes, change the package names to something like org.springframework.x.y
Affects: 5.0 GA
Issue Links: - #20509 spring-jcl does not include exported packages of java commons logging - #19081 Revisit Commons Logging vs java.util.logging vs SLF4J vs Log4j 2
Comment From: spring-projects-issues
Juergen Hoeller commented
This is by design: spring-jcl is a standard Commons Logging bridge just like jcl-over-slf4j is, with first-class support for Log4J 2 as well as SLF4J (instead of having to mess with manual excludes and extra bridges for either of those two). If you prefer a different bridge, you simply need to exclude spring-jcl from spring-core's dependencies... just like for a switch between regular commons-logging and jcl-over-slf4j against Spring Framework 4.
In other words, it's simply a new default logging bridge in Spring, primarily for backwards compatibility with existing Commons Logging API usage in the Spring ecosystem. For that reason, it's intentionally not repackaged into org.springframework. We took jcl-over-slf4j as an inspiration there; for all practical purposes, our spring-jcl is no more "against convention" than that standard SLF4J bridge or a default dependency on that bridge.
Point taken, you might have to adapt existing project dependency declarations in order to arrive at a clean classpath when upgrading to Spring Framework 5. If you're currently manually excluding commons-logging from spring-core's dependencies in order to bring in jcl-over-slf4j, simply exclude spring-jcl instead of commons-logging now... and your project classpath should be as clean as before, hanging on to your logging bridge of choice.
For a newly started project, no extra setup is necessary in the first place: Let spring-jcl do its job, picking up Log4J 2 or SLF4J or JUL by default, with no need for excludes or bridges. If you'd like to consistently use spring-jcl that way, you should simply exclude commons-logging and/or jcl-over-slf4j dependencies in other libraries that might bring those into your classpath by default. No fundamental difference, just another variant of such a bridge.
Comment From: Enerccio
This breaks anything that checks for "jar hell", such as elasticsearch when used as library and starting a plugin