[
https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18871#comment-18871
]
Stephen Colebourne commented on SLF4J-407:
------------------------------------------
I've written up a wiki page with SLF4J and Log4J to try and get a solid basis
for logging to work
https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs/_edit
The key choice is with the implementation projects which are strange because
only one is allowed.
For SLF4J, this is projects like slf4j-nop, slf4j-simple and logback-classic.
Either they all have the same module name, or they have different module names.
The argument for the same module name is that only one can be active at any one
time. By using the same module name, it allows the application to depend on "an
implementation of SLF4J" in `module-info` without explicitly specifying which
one.
If using different module names for each implementation, then when the
application developer writes the `module-info.java` file, they are picking an
explicit implementation of the API, which can't be changed at deploy time as it
would be locked into a `.class` file.
My gut feeling is that the former (same module name for all implementations) is
correct from a modular point of view, however developers would certainly find
it surprising initially because its not how maven artifacts work. Really we
could do with hearing an OSGi/JBoss modules viewpoint on the choice.
See also https://issues.apache.org/jira/browse/LOG4J2-2056
> Jigsaw modules contain clashing package
> ---------------------------------------
>
> Key: SLF4J-407
> URL: https://jira.qos.ch/browse/SLF4J-407
> Project: SLF4J
> Issue Type: Bug
> Components: Implementations
> Affects Versions: 1.8.0-alpha2
> Reporter: Stephen Colebourne
> Assignee: Ceki Gülcü
> Fix For: 1.8.0-beta0
>
>
> Looking at the slf4j-jdk14 and slf4j-nop artifacts, they both appear to
> contain the package `org.slf4j.impl`. Jigsaw will refuse to load two modules
> that contain the same package, so this will be a problem.
> I know that SLF4J does not intend users to load both of these modules at the
> same time. But the current setup means that it will be the JPMS runtime that
> rejects it, meaning that there is no chance for SLF4J to output a helpful
> message (as I believe it does today).
> The solution to this would appear to be to move the `org.slf4j.impl` package
> to `org.slf4j.jul.impl` and `org.slf4j.nop.impl`. As the impl package is not
> exported, this should not affect any user code (except code that would have
> been affected anyway).
> I imagine this affects other slf4j artifacts.
> I also note that [this
> module-info.java|https://github.com/qos-ch/slf4j/blob/1_8_0-SNAPSHOT/slf4j-jdk14/src/main/java/module-info.java]
> exports the `org.slf4j.jul` package, which seems unnecessary (simple and nop
> do not export their package).
> See [here|http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html] for
> more information on naming.
--
This message was sent by Atlassian JIRA
(v7.3.1#73012)
_______________________________________________
slf4j-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-dev
