[all] Java 9 module names

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[all] Java 9 module names

jodastephen
Hi All,
Java 9 is coming soon (unless it is delayed again, but that seems
unlikely). The major feature is JPMS, the Java Platform Module System.
While JPMS is far from ideal, projects like Apache Commons and mine
Joda-* are going to be key to getting some adoption. This is
particularly true as Commons projects tend to be at the base of the
dependency tree.

I've written up my recommendations for naming modules here:
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
Basically, it strongly recommends reverse-DNS naming based on the
super-package of a project.

What is needed now?

Apache Commons, and Apache in general, needs to agree to use a
consistent naming strategy for modules. As per my writeup, I strongly
recommend using the super-package name as the module name, as most
Apache projects already have good separation by package name.

It will be important to ensure complete separation however, as JPMS
does not allow the same package to be in two modules.

Finally, it is important to note that modules are not the same as
artifacts. Modules, and thus their names, represent the JVMs view of
the structure of an application. Artifacts are a transport mechanism
(jar file), and many different artifacts can provide the same module.
This becomes apparent when considering the Apache branded JSR jar
files, for example the module name might be javax.servlet (ie. not
referencing Apache), but the artifactId is apache-jsr-360 (which does
reference Apache).


So, how to apply this to Commons (and Apache in general)?

Well, I haven't examined each commons subproject, but from my time
contributing years ago, each subproject has its own package name.
Thus:

Commons-IO
-> super-package org.apache.commons.io
-> module org.apache.commons.io

Commons-Lang3
-> super-package org.apache.commons.lang3
-> module org.apache.commons.lang3


If everyone agrees, the module name for each project should be
documented somewhere on the website. Note that this should be done
_now_, but does not require creating a module-info.java file, or
otherwise preparing for Java 9.

Comments? Questions?
thanks
Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Robert Scholte
I support this.

Also good to know is that recently we managed to make the Jigsaw team  
reintroduce the NumberAtEnd[1] in the module name, which makes it again  
possible that commons-lang, commons-lang2 and commons-lang3 can live next  
to each other on the modulepath.

Robert

[1]  
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-March/000659.html


On Fri, 21 Apr 2017 14:00:06 +0200, Stephen Colebourne  
<[hidden email]> wrote:

> Hi All,
> Java 9 is coming soon (unless it is delayed again, but that seems
> unlikely). The major feature is JPMS, the Java Platform Module System.
> While JPMS is far from ideal, projects like Apache Commons and mine
> Joda-* are going to be key to getting some adoption. This is
> particularly true as Commons projects tend to be at the base of the
> dependency tree.
>
> I've written up my recommendations for naming modules here:
> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> Basically, it strongly recommends reverse-DNS naming based on the
> super-package of a project.
>
> What is needed now?
>
> Apache Commons, and Apache in general, needs to agree to use a
> consistent naming strategy for modules. As per my writeup, I strongly
> recommend using the super-package name as the module name, as most
> Apache projects already have good separation by package name.
>
> It will be important to ensure complete separation however, as JPMS
> does not allow the same package to be in two modules.
>
> Finally, it is important to note that modules are not the same as
> artifacts. Modules, and thus their names, represent the JVMs view of
> the structure of an application. Artifacts are a transport mechanism
> (jar file), and many different artifacts can provide the same module.
> This becomes apparent when considering the Apache branded JSR jar
> files, for example the module name might be javax.servlet (ie. not
> referencing Apache), but the artifactId is apache-jsr-360 (which does
> reference Apache).
>
>
> So, how to apply this to Commons (and Apache in general)?
>
> Well, I haven't examined each commons subproject, but from my time
> contributing years ago, each subproject has its own package name.
> Thus:
>
> Commons-IO
> -> super-package org.apache.commons.io
> -> module org.apache.commons.io
>
> Commons-Lang3
> -> super-package org.apache.commons.lang3
> -> module org.apache.commons.lang3
>
>
> If everyone agrees, the module name for each project should be
> documented somewhere on the website. Note that this should be done
> _now_, but does not require creating a module-info.java file, or
> otherwise preparing for Java 9.
>
> Comments? Questions?
> thanks
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Emmanuel Bourg-3
In reply to this post by jodastephen
Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :

> Comments? Questions?

Hi Stephen,

Thank you for stopping by and enlightening us about JPMS. The new module
system looks like a huge mess. I understand the need for modularization
at the JRE level, but I haven't figured out yet how this extra
complexity will improve my applications. I know you've followed the
development of this feature thoroughly and I trust your judgment. You
still have commit access to the Commons components, so I'd encourage you
to go ahead and implement your suggestion directly. Commons Lang 3.6 is
about to be released, we could start with this one and use it as an
example for the other components.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
Right now, I don't recommend adding a module-info.java file. Java 9 is
not released, the tools are still under development, and the binary
format may yet change. All we are agreeing is that the module name
will be `org.apache.commons.lang3`, which doesn't change the release
:-)

What we need is a page, either on each subproject website, or on the
main website (probably simpler) that lists the module names for each
project. I can try to find time to work on such a page, but although I
technically have commit access, I certainly don't in practical terms,
so I'd probably submit a GitHub PR instead.

When the time comes, the module-info.java file will be something like this:

module org.apache.commons.lang3 {
 exports org.apache.commons.lang3;
 exports org.apache.commons.lang3.builder;
 exports org.apache.commons.lang3.concurrent;
 exports org.apache.commons.lang3.event;
 exports org.apache.commons.lang3.exception;
 exports org.apache.commons.lang3.math;
 exports org.apache.commons.lang3.mutable;
 exports org.apache.commons.lang3.reflect;
 exports org.apache.commons.lang3.text;
 exports org.apache.commons.lang3.text.translate;
 exports org.apache.commons.lang3.time;
 exports org.apache.commons.lang3.tuple;
}

Stephen

On 21 April 2017 at 13:31, Emmanuel Bourg <[hidden email]> wrote:

> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>
>> Comments? Questions?
>
> Hi Stephen,
>
> Thank you for stopping by and enlightening us about JPMS. The new module
> system looks like a huge mess. I understand the need for modularization
> at the JRE level, but I haven't figured out yet how this extra
> complexity will improve my applications. I know you've followed the
> development of this feature thoroughly and I trust your judgment. You
> still have commit access to the Commons components, so I'd encourage you
> to go ahead and implement your suggestion directly. Commons Lang 3.6 is
> about to be released, we could start with this one and use it as an
> example for the other components.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

sebb-2-2
In reply to this post by jodastephen
On 21 April 2017 at 13:00, Stephen Colebourne <[hidden email]> wrote:

> Hi All,
> Java 9 is coming soon (unless it is delayed again, but that seems
> unlikely). The major feature is JPMS, the Java Platform Module System.
> While JPMS is far from ideal, projects like Apache Commons and mine
> Joda-* are going to be key to getting some adoption. This is
> particularly true as Commons projects tend to be at the base of the
> dependency tree.
>
> I've written up my recommendations for naming modules here:
> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html
> Basically, it strongly recommends reverse-DNS naming based on the
> super-package of a project.
>
> What is needed now?
>
> Apache Commons, and Apache in general, needs to agree to use a
> consistent naming strategy for modules. As per my writeup, I strongly
> recommend using the super-package name as the module name, as most
> Apache projects already have good separation by package name.
>
> It will be important to ensure complete separation however, as JPMS
> does not allow the same package to be in two modules.
>
> Finally, it is important to note that modules are not the same as
> artifacts. Modules, and thus their names, represent the JVMs view of
> the structure of an application. Artifacts are a transport mechanism
> (jar file), and many different artifacts can provide the same module.
> This becomes apparent when considering the Apache branded JSR jar
> files, for example the module name might be javax.servlet (ie. not
> referencing Apache), but the artifactId is apache-jsr-360 (which does
> reference Apache).
>
>
> So, how to apply this to Commons (and Apache in general)?
>
> Well, I haven't examined each commons subproject, but from my time
> contributing years ago, each subproject has its own package name.
> Thus:
>
> Commons-IO
> -> super-package org.apache.commons.io
> -> module org.apache.commons.io
>
> Commons-Lang3
> -> super-package org.apache.commons.lang3
> -> module org.apache.commons.lang3
>
>
> If everyone agrees, the module name for each project should be
> documented somewhere on the website. Note that this should be done
> _now_, but does not require creating a module-info.java file, or
> otherwise preparing for Java 9.
>
> Comments? Questions?

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

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).

> thanks
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

sebb-2-2
In reply to this post by jodastephen
On 21 April 2017 at 13:49, Stephen Colebourne <[hidden email]> wrote:
> Right now, I don't recommend adding a module-info.java file. Java 9 is
> not released, the tools are still under development, and the binary
> format may yet change. All we are agreeing is that the module name
> will be `org.apache.commons.lang3`, which doesn't change the release
> :-)
>
> What we need is a page, either on each subproject website, or on the
> main website (probably simpler) that lists the module names for each
> project.

IMO the easies to set up and maintain (at least initially) would be a
page on the Commons Wiki.

> I can try to find time to work on such a page, but although I
> technically have commit access, I certainly don't in practical terms,
> so I'd probably submit a GitHub PR instead.
>
> When the time comes, the module-info.java file will be something like this:
>
> module org.apache.commons.lang3 {
>  exports org.apache.commons.lang3;
>  exports org.apache.commons.lang3.builder;
>  exports org.apache.commons.lang3.concurrent;
>  exports org.apache.commons.lang3.event;
>  exports org.apache.commons.lang3.exception;
>  exports org.apache.commons.lang3.math;
>  exports org.apache.commons.lang3.mutable;
>  exports org.apache.commons.lang3.reflect;
>  exports org.apache.commons.lang3.text;
>  exports org.apache.commons.lang3.text.translate;
>  exports org.apache.commons.lang3.time;
>  exports org.apache.commons.lang3.tuple;
> }
>
> Stephen
>
> On 21 April 2017 at 13:31, Emmanuel Bourg <[hidden email]> wrote:
>> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>>
>>> Comments? Questions?
>>
>> Hi Stephen,
>>
>> Thank you for stopping by and enlightening us about JPMS. The new module
>> system looks like a huge mess. I understand the need for modularization
>> at the JRE level, but I haven't figured out yet how this extra
>> complexity will improve my applications. I know you've followed the
>> development of this feature thoroughly and I trust your judgment. You
>> still have commit access to the Commons components, so I'd encourage you
>> to go ahead and implement your suggestion directly. Commons Lang 3.6 is
>> about to be released, we could start with this one and use it as an
>> example for the other components.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
In reply to this post by sebb-2-2
On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
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 <[hidden email]> wrote:
>
> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Bernd Eckenfels
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 <[hidden email]>
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 <[hidden email]> wrote:
>
> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
Ok - it seems I missed that every package has to be individually specified. Where is the link to the spec for the module-info file. All I seem to be able to find with google are examples and descriptions.

Ralph

> On Apr 21, 2017, at 1:40 PM, Ralph Goers <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> wrote:
>>>
>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
I think I finally found it at http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html <http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html>.

Ralph

> On Apr 21, 2017, at 1:58 PM, Ralph Goers <[hidden email]> wrote:
>
> Ok - it seems I missed that every package has to be individually specified. Where is the link to the spec for the module-info file. All I seem to be able to find with google are examples and descriptions.
>
> Ralph
>
>> On Apr 21, 2017, at 1:40 PM, Ralph Goers <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]> wrote:
>>>>
>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Bernd Eckenfels
In reply to this post by Ralph Goers
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
In reply to this post by Ralph Goers
Some rules:
- Each module contains a set of packages, each of which must be
specified explicitly.
- Modules depend on other modules, but must not form a cycle of dependencies.
- No package can be in two modules

Looking at the Javadoc here -
https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
jar file has a separate set of packages it contains, with an obvious
super-package for each jar file*. Furthermore, the super-packages of
the jar files do not clash, so I think you are fine in naming terms.
What I can't be sure from the Javadoc is whether there is a cycle of
dependencies.

Possible modules:
- org.apache.logging.log4j
- org.apache.logging.log4j.core
- org.apache.logging.log4j.io
- org.apache.logging.log4j.taglib
- org.apache.logging.log4j.jcl
- org.apache.logging.log4j.jul
- org.apache.logging.log4j.flume.appender
- org.apache.logging.log4j.jmx.gui
- org.apache.logging.log4j.web
- org.apache.logging.log4j.nosql.appender

* the slf4j bridge is problematic, but is being addressed by changes in slf4j.
* the logf4 v1 bridge probably can't be modularized

Bernd has addressed the point about the need to export all packages
individually, allowing the modules above.

Stephen

On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:

> 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 <[hidden email]> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
In reply to this post by jodastephen
I've started a page here:
https://github.com/jodastephen/jpms-module-names/blob/master/README.md
Feel free to raise a PR with more projects at commons or elsewhere in
Apache - I'm just checking the Javadoc and releases to ensure there
are no problems.

Stephen



On 21 April 2017 at 13:49, Stephen Colebourne <[hidden email]> wrote:

> Right now, I don't recommend adding a module-info.java file. Java 9 is
> not released, the tools are still under development, and the binary
> format may yet change. All we are agreeing is that the module name
> will be `org.apache.commons.lang3`, which doesn't change the release
> :-)
>
> What we need is a page, either on each subproject website, or on the
> main website (probably simpler) that lists the module names for each
> project. I can try to find time to work on such a page, but although I
> technically have commit access, I certainly don't in practical terms,
> so I'd probably submit a GitHub PR instead.
>
> When the time comes, the module-info.java file will be something like this:
>
> module org.apache.commons.lang3 {
>  exports org.apache.commons.lang3;
>  exports org.apache.commons.lang3.builder;
>  exports org.apache.commons.lang3.concurrent;
>  exports org.apache.commons.lang3.event;
>  exports org.apache.commons.lang3.exception;
>  exports org.apache.commons.lang3.math;
>  exports org.apache.commons.lang3.mutable;
>  exports org.apache.commons.lang3.reflect;
>  exports org.apache.commons.lang3.text;
>  exports org.apache.commons.lang3.text.translate;
>  exports org.apache.commons.lang3.time;
>  exports org.apache.commons.lang3.tuple;
> }
>
> Stephen
>
> On 21 April 2017 at 13:31, Emmanuel Bourg <[hidden email]> wrote:
>> Le 21/04/2017 à 14:00, Stephen Colebourne a écrit :
>>
>>> Comments? Questions?
>>
>> Hi Stephen,
>>
>> Thank you for stopping by and enlightening us about JPMS. The new module
>> system looks like a huge mess. I understand the need for modularization
>> at the JRE level, but I haven't figured out yet how this extra
>> complexity will improve my applications. I know you've followed the
>> development of this feature thoroughly and I trust your judgment. You
>> still have commit access to the Commons components, so I'd encourage you
>> to go ahead and implement your suggestion directly. Commons Lang 3.6 is
>> about to be released, we could start with this one and use it as an
>> example for the other components.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
In reply to this post by jodastephen
Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.

Ralph

> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>
> Some rules:
> - Each module contains a set of packages, each of which must be
> specified explicitly.
> - Modules depend on other modules, but must not form a cycle of dependencies.
> - No package can be in two modules
>
> Looking at the Javadoc here -
> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
> jar file has a separate set of packages it contains, with an obvious
> super-package for each jar file*. Furthermore, the super-packages of
> the jar files do not clash, so I think you are fine in naming terms.
> What I can't be sure from the Javadoc is whether there is a cycle of
> dependencies.
>
> Possible modules:
> - org.apache.logging.log4j
> - org.apache.logging.log4j.core
> - org.apache.logging.log4j.io
> - org.apache.logging.log4j.taglib
> - org.apache.logging.log4j.jcl
> - org.apache.logging.log4j.jul
> - org.apache.logging.log4j.flume.appender
> - org.apache.logging.log4j.jmx.gui
> - org.apache.logging.log4j.web
> - org.apache.logging.log4j.nosql.appender
>
> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
> * the logf4 v1 bridge probably can't be modularized
>
> Bernd has addressed the point about the need to export all packages
> individually, allowing the modules above.
>
> Stephen
>
> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>> 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 <[hidden email]> wrote:
>>>
>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Ralph Goers
On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.

Ralph

> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>
> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>
> Ralph
>
>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>
>> Some rules:
>> - Each module contains a set of packages, each of which must be
>> specified explicitly.
>> - Modules depend on other modules, but must not form a cycle of dependencies.
>> - No package can be in two modules
>>
>> Looking at the Javadoc here -
>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>> jar file has a separate set of packages it contains, with an obvious
>> super-package for each jar file*. Furthermore, the super-packages of
>> the jar files do not clash, so I think you are fine in naming terms.
>> What I can't be sure from the Javadoc is whether there is a cycle of
>> dependencies.
>>
>> Possible modules:
>> - org.apache.logging.log4j
>> - org.apache.logging.log4j.core
>> - org.apache.logging.log4j.io
>> - org.apache.logging.log4j.taglib
>> - org.apache.logging.log4j.jcl
>> - org.apache.logging.log4j.jul
>> - org.apache.logging.log4j.flume.appender
>> - org.apache.logging.log4j.jmx.gui
>> - org.apache.logging.log4j.web
>> - org.apache.logging.log4j.nosql.appender
>>
>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>> * the logf4 v1 bridge probably can't be modularized
>>
>> Bernd has addressed the point about the need to export all packages
>> individually, allowing the modules above.
>>
>> Stephen
>>
>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>> 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 <[hidden email]> wrote:
>>>>
>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

Matt Sicker
Despite all the shit the Java champions talk about OSGi, Jigsaw is still a
simplified version of OSGi basically, so anything already supported via
OSGi will generally port extremely easily to Java 9 modules.

As for the optional modules, it sounds like static module imports are the
way to declare optional modules, though I don't know the details.

On 21 April 2017 at 20:11, Ralph Goers <[hidden email]> wrote:

> On to the next question - which I apologize for asking as it may not apply
> to Commons.  Log4j has lots of optional components to support lots of third
> party stuff (some ASF projects and some not). How do we handle things that
> haven’t yet been modularized? Normally I would expect to have requires
> directives.
>
> Ralph
>
> > On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]>
> wrote:
> >
> > Thanks for taking a look Stephen. I appreciate the guidance. I will be
> sure to submit a PR when I get something going with Log4j 2.
> >
> > Ralph
> >
> >> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]>
> wrote:
> >>
> >> Some rules:
> >> - Each module contains a set of packages, each of which must be
> >> specified explicitly.
> >> - Modules depend on other modules, but must not form a cycle of
> dependencies.
> >> - No package can be in two modules
> >>
> >> Looking at the Javadoc here -
> >> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
> >> jar file has a separate set of packages it contains, with an obvious
> >> super-package for each jar file*. Furthermore, the super-packages of
> >> the jar files do not clash, so I think you are fine in naming terms.
> >> What I can't be sure from the Javadoc is whether there is a cycle of
> >> dependencies.
> >>
> >> Possible modules:
> >> - org.apache.logging.log4j
> >> - org.apache.logging.log4j.core
> >> - org.apache.logging.log4j.io
> >> - org.apache.logging.log4j.taglib
> >> - org.apache.logging.log4j.jcl
> >> - org.apache.logging.log4j.jul
> >> - org.apache.logging.log4j.flume.appender
> >> - org.apache.logging.log4j.jmx.gui
> >> - org.apache.logging.log4j.web
> >> - org.apache.logging.log4j.nosql.appender
> >>
> >> * the slf4j bridge is problematic, but is being addressed by changes in
> slf4j.
> >> * the logf4 v1 bridge probably can't be modularized
> >>
> >> Bernd has addressed the point about the need to export all packages
> >> individually, allowing the modules above.
> >>
> >> Stephen
> >>
> >> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]>
> wrote:
> >>> 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 <[hidden email]>
> wrote:
> >>>>
> >>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
In reply to this post by Ralph Goers
See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction

Basically, you need "requires static" for optional dependencies. The
exception if for a module where the dependency is an annotation where
you don't need the annotation to be present at runtime. eg. @NonNull
from FindBugs

Depending on things that haven't been modularized yet is risky. It is
allowed however, and its known as "automatic modules". Basically, it
looks exactly like a normal "requires" clause, its just that you are
_guessing_ what the module name of the dependency will be!

This is why I started this thread. By saying _now_what the module name
will be, you greatly reduce the chance of people guessing wrongly.
Getting everyone to usesuper-package reverse DNS naming helps too.

Stephen


On 22 April 2017 at 02:11, Ralph Goers <[hidden email]> wrote:

> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>
> Ralph
>
>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>
>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>
>>> Some rules:
>>> - Each module contains a set of packages, each of which must be
>>> specified explicitly.
>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>> - No package can be in two modules
>>>
>>> Looking at the Javadoc here -
>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>> jar file has a separate set of packages it contains, with an obvious
>>> super-package for each jar file*. Furthermore, the super-packages of
>>> the jar files do not clash, so I think you are fine in naming terms.
>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>> dependencies.
>>>
>>> Possible modules:
>>> - org.apache.logging.log4j
>>> - org.apache.logging.log4j.core
>>> - org.apache.logging.log4j.io
>>> - org.apache.logging.log4j.taglib
>>> - org.apache.logging.log4j.jcl
>>> - org.apache.logging.log4j.jul
>>> - org.apache.logging.log4j.flume.appender
>>> - org.apache.logging.log4j.jmx.gui
>>> - org.apache.logging.log4j.web
>>> - org.apache.logging.log4j.nosql.appender
>>>
>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>> * the logf4 v1 bridge probably can't be modularized
>>>
>>> Bernd has addressed the point about the need to export all packages
>>> individually, allowing the modules above.
>>>
>>> Stephen
>>>
>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>> 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 <[hidden email]> wrote:
>>>>>
>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [all] Java 9 module names

jodastephen
In reply to this post by Matt Sicker
On 22 April 2017 at 05:18, Matt Sicker <[hidden email]> wrote:
> Despite all the shit the Java champions talk about OSGi, Jigsaw is still a
> simplified version of OSGi basically, so anything already supported via
> OSGi will generally port extremely easily to Java 9 modules.

JPMS (Jigsaw) is not a simplified OSGi. The two really have very
little in common at this point. It is also nigh on impossible to run
OSGi and JPMS modules together. JPMS does not have dynamic behaviour,
the cornerstone of OSGi. It also does not have any way for a consumer
of modules to fix bad metadata.

As such, I don't think this is a helpful comparison at this point. My
goal (as a Java Champion) is to try and ensure that the community
works the best it can with JPMS, even is I think JPMS has real flaws.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...