[
https://jira.qos.ch/browse/SLF4J-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18956#comment-18956
]
Stephen Colebourne commented on SLF4J-407:
------------------------------------------
Log4J also mentioned a use case where multiple implementations might be loaded
and one selected at runtime, or perhaps even more than one used, requirements
that need different module names for each implementation. SLF4J is slightly
different as currently many of the implementations share the same package.
The real concern here is about mistakes - where a bad module on Maven Central
includes the implementation as a dependency. Linked to that is the point above
about recompiling module-info to change implementation (although the command
line --add-modules flag can sidestep that).
The question is whether option 1 (forcing all implementations to have the same
module name) is the right reaction to the concerns.
Initiallly I thought the bad module case had no ability to work around it.
However, it turns out there is a way to work around. You have to create an
empty module with the name of the logging implementation that you don't want to
satisfy the dependency. I've come to the conclusion that Maven should do this
if necessary (when it sees an exclude clause).
Given that there is a workaround, option 2 seems more like the way to go,
although I do think we should ask the authors of JPMS on the Oracle mailing
lists,
> 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-beta1
>
>
> 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
