In the case of Commons Logging, Log4j 2 works that way - Commons Logging uses log4j-jcl as its implementation. But SLF4J replaces Commons Logging with slf4j-over-jcl, so you must make sure the commons-logging jar is not present. What Stephen is saying is that in that case commons-logging and slf4j-over-jcl must have the same module name. I frankly find that confusing and would have instead preferred that each module have a variation of provides that names the feature being provided, but such is life. (As an aside, this would have also let a jar contain multiple modules).
Ralph > On Apr 24, 2017, at 2:38 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > Hm, I don't think a bridge implementation needs to fake a (API) module. > > Your client code requires the API module and no specific implementation. The > implementations (including the bridge) export their specific packages to the > API module (optionally with service provider for discovery). > > This is basically the same as with OSGi (only that modules allow friends > easier). The runtime scope in maven would be for those modules which are not > explicitely required but needed at runtime. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > From: jodastep...@gmail.com <jodastep...@gmail.com> on behalf of Stephen > Colebourne <scolebou...@joda.org> > Sent: Monday, April 24, 2017 1:42:33 PM > To: Commons Developers List > Subject: Re: [all] Java 9 module names > > On 24 April 2017 at 11:08, Jörg Schaible <joerg.schai...@bpm-inspire.com> > wrote: >> Stephen Colebourne wrote: >> >>> Sounds like you could use --add-modules to add the module separately >>> from the command line, or add the module to the application's >>> module-info rather than the libraries. >>> >>> In general, I suspect a library module-info.java should depend only on >>> the other modules it really needs (eg. the API of slf4j), while >>> something else, such as the application, adds the implementation >>> module (eg. the SLF4J implementation). >> >> Which will create another chaos. Currently I can use the the xx-over-yy >> artifacts to replace a hard coded dependency of an artifact if it is >> required to embed it in a larger system. > > You still can. See my latest blog for the mental model you need: > http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html > > TL;DR, modules != artifacts. Depending on a module does not imply > depending on exactly the same artifact that was used at compile time. > Thus, the xx-over-yy jar files are still useful, provided they have > the same module name as the module they are faking. See > https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking. > > Stephen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
