ClaudioElio opened SPR-17398 and commented

Hi

I wonder why has been created this package instead of extending the spring-jcl

if needed, it would be necessary not to call inner implementation of common-logging or Java 9 Module mechanism (that I'm trying to fit to Spring Framework in my spare time) is giving duplicated module exception (split package)

Thanks 

Affects: 5.1.1

Reference URL: https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/log/CompositeLog.java

Comment From: spring-projects-issues

Juergen Hoeller commented

These utilities are external since spring-jcl is meant to be a plain Commons Logging replacement. spring-core needs to keep working even if spring-jcl.jar is being replaced with a standard commons-logging.jar or jcl-over-slf4j.jar.

That said, NoOpLog is present in all Commons Logging variants out there. The .impl package is part of the public surface there already, with quite a few other libraries depending on it. What specifically are you trying to accomplish? Exporting org.apache.commons.logging only but not the .impl subpackage in a module-info descriptor for spring-jcl?

Comment From: spring-projects-issues

ClaudioElio commented

Hi Juergen

thanks for the answer

I try to expose my thougths

both spring-jcl and spring-core depends on commons-logging and this is transformed in split-package problem

so I think IMHO that it should be managed in a different way  :)

I'm trying now to work on module-info to avoid the problem.. I hope it works but it could be a work-around

If all spring-framework is going to be "modularized" I think it should be one of issue

Comment From: spring-projects-issues

Juergen Hoeller commented

Note that spring-jcl is a variant of Commons Logging, effectively an alternative to the standard commons-logging.jar or jcl-over-slf4j.jar which it can be replaced with. spring-core is designed to work with either of those three variants; it just runs against spring-jcl by default. There is no actual split package problem there, just alternative implementations of org.apache.commons.logging and org.apache.commons.logging.impl. This is perfectly compatible with the module system as long as only one of those alternatives is present on a concrete module path.

As for the public exposure of the impl package, this is unavoidable as far as I can see. Long-evolved 'modules' such as Commons Logging and also the Spring Framework jars have a large public surface area that is hard to reduce. Frameworks in particular do not only have an API, they also provide SPIs and convenience classes for implementors... all of which need to be exposed, just not necessarily to the same audience. In any case, from a module declaration perspective, all of those packages have to be exported, including org.apache.commons.logging.impl which can then be used in spring-core and other close collaborators without any visibility or split package problems.

Comment From: spring-projects-issues

ClaudioElio commented

ok thank you for the answer. So if I understand correctly you are saying that at runtime there not will be problems as spring-jcl should be deployed only in absence of commons-logging and therefore is only a build problem?

Comment From: bclozel

Closing has this matter has been resolved.