No packages are not hierarchical.
There is for example a java.sql and java.sql.rowset module. (The first contains
java.sql and javax.sql the later javax.sql.rowset and
javax.sql.rowset.{serial,spi}. Or module java.desktop contains Java.awt and
Java.datatransfer contains java.awt.datatransfer. In fact java.util.logging
comes from java.logging while java.util is in java.base.
http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html
The only inclusion dependency is in source archives as they require a new level
directory per each module.
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Friday, April 21, 2017 10:40:01 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names
How do I export org.apache.logging.log4j from the log4j-api module and then be
able to export org.apache.logging.log4j.core from the log4j-core module? My
understanding is that exporting a package exports that package and those
beneath it. Is that incorrect?
Ralph
> On Apr 21, 2017, at 1:37 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
>
> Around what? there is no problem to have multiple packages in multiple
> modules depending on each other (if you decide to ship modules at all). Only
> split packages is a problem (but this is also a problem for OSGi or code
> signing so nobody should really use that anyway)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: Ralph Goers <ralph.go...@dslextreme.com>
> Sent: Friday, April 21, 2017 10:34:36 PM
> To: Commons Developers List
> Subject: Re: [all] Java 9 module names
>
> I am having a hard time figuring out how Log4j is going to be able to support
> this. The API itself is in org.apache.logging.log4j and some packages under
> that. All the main implementation is under org.apache.logging.log4j.core.
> These obviously overlap. Most of our other jars have packages that are in
> org.apache.logging.log4j.xxx where xxx matches the jar name. We aren’t going
> to change the API to support modules.
>
> Is there some reasonable way around this?
>
> Ralph
>
>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote:
>>> What happens when there is a API break which necessitates a package name
>>> change?
>>> I assume that the module name will also need to change to the new
>>> super-package.
>>> e.g.
>>>
>>> Commons-Lang4
>>> -> super-package org.apache.commons.lang4
>>> -> module org.apache.commons.lang4
>>
>> Yes, thats right.
>>
>>> AFAICT Commons generally has obvious and unique super-packages for
>>> each component.
>>> This should make it easier than for larger projects with lots of jars
>>> and potentially overlapping package names.
>>>
>>> However even Commons has some code that uses a different package structure.
>>> e.g. NET uses examples as the super-package.
>>> This includes working examples that are included in the release.
>>> I guess that will have to change (which is probably a good idea anyway).
>>
>> Yes, as it stands, [net] would be a bad modular citizen, because it
>> exposes the "examples" package, and thus prevents any other module
>> from using that package. Just move it to
>> org.apache.commons.net.examples.
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
