While true that would be immensely confusing to users I think. However, if two modules have the same packages in them you will get an error at runtime.
"Now consider again the key restriction that a package must be found in one and only one module. This restriction applies to hidden packages as well as exported ones. Therefore if your application depends on two modules and both have the same hidden package, your application cannot be run as the packages clash" Ralph > On Sep 11, 2017, at 10:30 PM, Remko Popma <[email protected]> wrote: > > Isn't it the opposite? Giving them the same module name will prevents them > from being used together, which is what we want: > > http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html?m=1 > "JPMS will simply refuse to start a modulepath where two modules have the > same name, even if they contain different packages." > > (Shameless plug) Every java main() method deserves http://picocli.info > >> On Sep 12, 2017, at 13:29, Ralph Goers <[email protected]> wrote: >> >> Actually, re-reading this again makes it clear to me that log4j-slf4j-impl >> and log4j-to-slf4j SHOULD use the same package name as it prevents them from >> both being present at the same time. Obviously, their module names still >> have to be different but this could mean the code doesn’t really need to be >> modified. >> >> Ralph >> >>> On Sep 11, 2017, at 6:26 PM, Matt Sicker <[email protected]> wrote: >>> >>> Is it possible to make the JPMS module names the same as the OSGi ones? The >>> default OSGi naming scheme is basically: >>> >>> groupId: org.apache.logging.log4j, artifactId: log4j-foo becomes bundleId: >>> org.apache.logging.log4j.foo >>> >>>> On 11 September 2017 at 13:01, Gary Gregory <[email protected]> wrote: >>>> >>>> On Mon, Sep 11, 2017 at 11:27 AM, Ralph Goers <[email protected]> >>>> wrote: >>>> >>>>> I know we discussed module names in the past and decided not to go the >>>>> route of modularizing now - in fact, we can’t until all of our >>>> dependencies >>>>> are modularized. However, we can (and probably should) add the automatic >>>>> module name as a manifest entry to each of our jars. My understanding is >>>>> that these would be the package name of the individual modules. For the >>>>> most part this should be trivial given the structure of our code base. >>>>> However I have two concerns: >>>>> >>>>> The package name used in log4j-api is org.apache.logging.log4j. My >>>>> understanding is that the module name should match the package name, but >>>> I >>>>> suspect most people would expect the module name to be >>>>> org.apache.logging.log4j.api. >>>>> >>>> >>>> I think we can leave that one as is. The package is >>>> org.apache.logging.log4j and that seems reasonable. It's the module >>>> name/artifact ID that we chose that is "different". If anything, I would >>>> change that. >>>> >>>> >>>>> Both log4j-slf4j-impl and log4j-to-slf4j use org.apache.loggingj.slf4j. >>>>> Notice that neither has log4j in the package name. These need to be >>>>> separate packages to be able to define module names to them. >>>>> >>>>> Thoughts? >>>>> >>>> >>>> I think we should just bite the bullet and repackage these two under >>>> org.apache.logging.log4j. That means changing the module name and artifact >>>> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j? >>>> A bit wordy... proposals? >>>> >>>> Gary >>>> >>>> >>>>> Ralph >>>> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >> >>
