Deprecate jcl-over-slf4j for removal

[ppkarwasz]

Since Commons Logging 1.3.0 natively supports SLF4J as a backend (cf. apache/commons-logging#177), the jcl-over-slf4j artifact became redundant.

The artifact uses the org.apache.commons.logging namespace, which can cause problems in a JPMS environment.

cc/ @garydgregory

[hazendaz]

For jcl-over-slf4j, at least for my day job, so many don't understand that spring-jcl replaced that part as does commons-logging now. And not everything used spring. I had written a few common modules that used slf4j as listeners to log a lot of startup information along with manifest data to make debugging far easier. So in that concept, I had to stick purely with jcl-over-slf4j as not spring. Then we have our pipelines bark if users are detected with both spring-jcl and jcl-over-slf4j. Further we made our super poms entirely ban commons-logging outright. So it would be good to get rid of jcl-over-slf4j. Same goes on the ticket at spring to get rid of spring-jcl. In my case at least I could then remove the mixed usage and if we detect invalid usage we could just fail builds without regard and make users fix the issue and/or and ban the new deprecated ones while allowing commons-logging again.

What would be great though over at commons-logging would be to retire the commons-logging group id and switch to org.apache.commons instead. That way we could still ban the legacy outright without concern of some lower version winning out due to transient resolutions. Just a thought! I thought apache commons was going that way at one point but most modules never did.

[garydgregory]

Hi all. Gary from Apache Commons here. We can't have the same Java namespace under two different Maven coordinates, this would cause jar hell plus JPMS problems. The only way to change the group id is if we also change the Java package name, and from the Commons Logging POV, there is no reason to do that until we go a 2.0 release which is not planned ATM.