You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@joda.org> on 2017/04/21 12:00:06 UTC
[all] Java 9 module names
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Robert Scholte <rf...@apache.org>.
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
<sc...@joda.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Matt Sicker <bo...@gmail.com>.
With regards to Log4j 1, just making v2 as compatible as possible with v1
should hopefully be enough.
As for lang v2, is there nothing stopping us from releasing a 2.7 artifact
with Java 9 support? Same goes for older major versions of Commons projects.
On 22 April 2017 at 13:03, Gary Gregory <ga...@gmail.com> wrote:
> What a mess. I wonder if we should do something more official with log4j1.
> I guess we can wait and see...
>
> On Apr 22, 2017 10:59 AM, "Ralph Goers" <ra...@dslextreme.com>
> wrote:
>
> > Gary, if you are transitioning to use Java 9 modules I think it is
> > appropriate that it be expected that only the latest versions will
> support
> > them. Upgrading to Java 9 is not going to be as simple as just replacing
> > the java runtime and running. They have removed lots of deprecated
> classes.
> > See http://www.infoworld.com/article/3171299/java/oracle-
> > preps-developers-for-java-9-upgrade.html <http://www.infoworld.com/
> > article/3171299/java/oracle-preps-developers-for-java-9-upgrade.html>.
> > Heck, we know that even Log4j 1.x has problems without a hack to fix it
> > (see https://github.com/qos-ch/slf4j/commit/01e56add155e723640 <
> > https://github.com/qos-ch/slf4j/commit/01e56add155e723640>).
> >
> > Ralph
> >
> > > On Apr 22, 2017, at 10:49 AM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > > On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> > > pascalschumacher@gmx.net <ma...@gmx.net>> wrote:
> > >
> > >> Is this really necessary?
> > >>
> > >> Imho people who use (update to) java 9 should not use these "ancient"
> > >> versions but update.
> > >>
> > >
> > > Sadly this is unrealistic and at times impossible due to transitive
> > > dependencies. I can't update my classpath from Commons Lang 2 to 3 if a
> > > third party depends on 2. What I end up with is my custom code updated
> > to 3
> > > and 2 still on the CP to support third parties.
> > >
> > > Gary
> > >
> > >>
> > >> Am 22.04.2017 um 10:00 schrieb Emmanuel Bourg:
> > >>
> > >>> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
> > >>>
> > >>>> 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.
> > >>>>
> > >>> Seeing Commons Lang 2 in the list I realize we'll have to dust off
> the
> > >>> old branches and publish new releases (lang 2.x, configuration 1.x,
> > jexl
> > >>> 2.x, math 3.x, pool 1.x, etc).
> > >>>
> > >>> Emmanuel Bourg
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
> > ggregory@apache.org <ma...@apache.org>
> > > Java Persistence with Hibernate, Second Edition
> > > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> <
> > https://www.amazon.com/gp/product/1617290459/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2
> b8>>
> > >
> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > 1617290459 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> > am2&o=1&a=1617290459>>
> > > JUnit in Action, Second Edition
> > > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> 18%22
> > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de4
> 18%22
> > >>
> > >
> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > 1935182021 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> > am2&o=1&a=1935182021>>
> > > Spring Batch in Action
> > > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> > tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> > linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> > 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action <https://www.amazon.com/gp/
> > product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=
> > 9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&
> > tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+
> Batch+in+Action
> > >>
> > > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> > 1935182951 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> > am2&o=1&a=1935182951>>
> > > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.
> > com/>
> > > Home: http://garygregory.com/ <http://garygregory.com/>
> > > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [all] Java 9 module names
Posted by Gary Gregory <ga...@gmail.com>.
What a mess. I wonder if we should do something more official with log4j1.
I guess we can wait and see...
On Apr 22, 2017 10:59 AM, "Ralph Goers" <ra...@dslextreme.com> wrote:
> Gary, if you are transitioning to use Java 9 modules I think it is
> appropriate that it be expected that only the latest versions will support
> them. Upgrading to Java 9 is not going to be as simple as just replacing
> the java runtime and running. They have removed lots of deprecated classes.
> See http://www.infoworld.com/article/3171299/java/oracle-
> preps-developers-for-java-9-upgrade.html <http://www.infoworld.com/
> article/3171299/java/oracle-preps-developers-for-java-9-upgrade.html>.
> Heck, we know that even Log4j 1.x has problems without a hack to fix it
> (see https://github.com/qos-ch/slf4j/commit/01e56add155e723640 <
> https://github.com/qos-ch/slf4j/commit/01e56add155e723640>).
>
> Ralph
>
> > On Apr 22, 2017, at 10:49 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> > pascalschumacher@gmx.net <ma...@gmx.net>> wrote:
> >
> >> Is this really necessary?
> >>
> >> Imho people who use (update to) java 9 should not use these "ancient"
> >> versions but update.
> >>
> >
> > Sadly this is unrealistic and at times impossible due to transitive
> > dependencies. I can't update my classpath from Commons Lang 2 to 3 if a
> > third party depends on 2. What I end up with is my custom code updated
> to 3
> > and 2 still on the CP to support third parties.
> >
> > Gary
> >
> >>
> >> Am 22.04.2017 um 10:00 schrieb Emmanuel Bourg:
> >>
> >>> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
> >>>
> >>>> 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.
> >>>>
> >>> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
> >>> old branches and publish new releases (lang 2.x, configuration 1.x,
> jexl
> >>> 2.x, math 3.x, pool 1.x, etc).
> >>>
> >>> Emmanuel Bourg
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com <ma...@gmail.com> |
> ggregory@apache.org <ma...@apache.org>
> > Java Persistence with Hibernate, Second Edition
> > <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8 <
> https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>>
> >
> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> am2&o=1&a=1617290459>>
> > JUnit in Action, Second Edition
> > <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >>
> >
> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> am2&o=1&a=1935182021>>
> > Spring Batch in Action
> > <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action <https://www.amazon.com/gp/
> product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=
> 9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&
> tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action
> >>
> > <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=
> am2&o=1&a=1935182951>>
> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.
> com/>
> > Home: http://garygregory.com/ <http://garygregory.com/>
> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary, if you are transitioning to use Java 9 modules I think it is appropriate that it be expected that only the latest versions will support them. Upgrading to Java 9 is not going to be as simple as just replacing the java runtime and running. They have removed lots of deprecated classes. See http://www.infoworld.com/article/3171299/java/oracle-preps-developers-for-java-9-upgrade.html <http://www.infoworld.com/article/3171299/java/oracle-preps-developers-for-java-9-upgrade.html>. Heck, we know that even Log4j 1.x has problems without a hack to fix it (see https://github.com/qos-ch/slf4j/commit/01e56add155e723640 <https://github.com/qos-ch/slf4j/commit/01e56add155e723640>).
Ralph
> On Apr 22, 2017, at 10:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> pascalschumacher@gmx.net <ma...@gmx.net>> wrote:
>
>> Is this really necessary?
>>
>> Imho people who use (update to) java 9 should not use these "ancient"
>> versions but update.
>>
>
> Sadly this is unrealistic and at times impossible due to transitive
> dependencies. I can't update my classpath from Commons Lang 2 to 3 if a
> third party depends on 2. What I end up with is my custom code updated to 3
> and 2 still on the CP to support third parties.
>
> Gary
>
>>
>> Am 22.04.2017 um 10:00 schrieb Emmanuel Bourg:
>>
>>> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>>>
>>>> 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.
>>>>
>>> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
>>> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
>>> 2.x, math 3.x, pool 1.x, etc).
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8 <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951 <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: [all] Java 9 module names
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
pascalschumacher@gmx.net> wrote:
> Is this really necessary?
>
> Imho people who use (update to) java 9 should not use these "ancient"
> versions but update.
>
Sadly this is unrealistic and at times impossible due to transitive
dependencies. I can't update my classpath from Commons Lang 2 to 3 if a
third party depends on 2. What I end up with is my custom code updated to 3
and 2 still on the CP to support third parties.
Gary
>
> Am 22.04.2017 um 10:00 schrieb Emmanuel Bourg:
>
>> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>>
>>> 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.
>>>
>> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
>> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
>> 2.x, math 3.x, pool 1.x, etc).
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [all] Java 9 module names
Posted by Pascal Schumacher <pa...@gmx.net>.
Is this really necessary?
Imho people who use (update to) java 9 should not use these "ancient"
versions but update.
Am 22.04.2017 um 10:00 schrieb Emmanuel Bourg:
> Le 22/04/2017 � 01:02, Stephen Colebourne a �crit :
>> 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.
> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
> 2.x, math 3.x, pool 1.x, etc).
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Robert Scholte <rf...@apache.org>.
Avoid references to auto modules. Here's the official advice:
- Strongly advise developers never to publish, for broad use, explicit
modules that require automatic modules. That's risky: An automatic
module is unreliable, since it can depend on types on the class path,
and its name and exported packages could change if and when it's
converted into an explicit module. It's fine to declare and use
explicit modules that require automatic modules in limited settings,
but they should never be published to Maven Central or any similar
public repository.
Robert
On Sat, 22 Apr 2017 16:25:55 +0200, Bernd Eckenfels
<ec...@zusammenkunft.net> wrote:
> Hm, never had the idea this is needed. I can see that new projects want
> a pure modules setting, for existing code (using older artifacts) that
> is less of an requirement. Hm, let's hope people who want modules
> versions will contribute.
>
> But the hint with automatic modules (file name based) is a good one (as
> long as they do not require imports?)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: jodastephen@gmail.com <jo...@gmail.com> on behalf of Stephen
> Colebourne <sc...@joda.org>
> Sent: Saturday, April 22, 2017 10:16:40 AM
> To: Commons Developers List
> Subject: Re: [all] Java 9 module names
>
> On 22 April 2017 at 09:00, Emmanuel Bourg <eb...@apache.org> wrote:
>> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>>> 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.
>>
>> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
>> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
>> 2.x, math 3.x, pool 1.x, etc).
>
> Not necessarily. So long as you specify what the module name would be,
> people can in theory use them via the "automatic module" feature. This
> may require some changes to maven to map artifacts to modules.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hm, never had the idea this is needed. I can see that new projects want a pure modules setting, for existing code (using older artifacts) that is less of an requirement. Hm, let's hope people who want modules versions will contribute.
But the hint with automatic modules (file name based) is a good one (as long as they do not require imports?)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: jodastephen@gmail.com <jo...@gmail.com> on behalf of Stephen Colebourne <sc...@joda.org>
Sent: Saturday, April 22, 2017 10:16:40 AM
To: Commons Developers List
Subject: Re: [all] Java 9 module names
On 22 April 2017 at 09:00, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>> 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.
>
> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
> 2.x, math 3.x, pool 1.x, etc).
Not necessarily. So long as you specify what the module name would be,
people can in theory use them via the "automatic module" feature. This
may require some changes to maven to map artifacts to modules.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
On 22 April 2017 at 09:00, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
>> 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.
>
> Seeing Commons Lang 2 in the list I realize we'll have to dust off the
> old branches and publish new releases (lang 2.x, configuration 1.x, jexl
> 2.x, math 3.x, pool 1.x, etc).
Not necessarily. So long as you specify what the module name would be,
people can in theory use them via the "automatic module" feature. This
may require some changes to maven to map artifacts to modules.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 22/04/2017 � 01:02, Stephen Colebourne a �crit :
> 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.
Seeing Commons Lang 2 in the list I realize we'll have to dust off the
old branches and publish new releases (lang 2.x, configuration 1.x, jexl
2.x, math 3.x, pool 1.x, etc).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
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 <sc...@joda.org> 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 <eb...@apache.org> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by sebb <se...@gmail.com>.
On 21 April 2017 at 13:49, Stephen Colebourne <sc...@joda.org> 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 <eb...@apache.org> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
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 <eb...@apache.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Emmanuel Bourg <eb...@apache.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
On 22 April 2017 at 05:18, Matt Sicker <bo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com>
> 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 <sc...@joda.org>
> 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 <ra...@dslextreme.com>
> 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 <sc...@joda.org>
> wrote:
> >>>>
> >>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [all] Java 9 module names
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hm why is that? What step in your compile would need the runtime module?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Ralph Goers <ra...@dslextreme.com>
Sent: Sunday, April 23, 2017 7:14:02 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names
Yes, I know it doesn't replace Maven, but in this case I have a dependency that is not required to compile but is required to run. It appears I have to convert my runtime scopes to compile in order to get the module to compile and build properly.
That sucks.
Sent from my iPhone
> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <sc...@joda.org> wrote:
>
> I've never used that myself, but don't see anything similar.
> Remember though that JPMS isn't trying to replace Maven. It just
> intends there to be a reliable set of modules when running in the
> platform.
> Stephen
>
>
>> On 23 April 2017 at 08:57, Ralph Goers <ra...@dslextreme.com> wrote:
>> How does the module system support Maven’s runtime scope?
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <sc...@joda.org> wrote:
>>>
>>> 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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>>>>
>>>>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
In the case of Commons Logging, Log4j 2 works that way - Commons Logging uses log4j-jcl as its implementation. But SLF4J replaces Commons Logging with slf4j-over-jcl, so you must make sure the commons-logging jar is not present. What Stephen is saying is that in that case commons-logging and slf4j-over-jcl must have the same module name. I frankly find that confusing and would have instead preferred that each module have a variation of provides that names the feature being provided, but such is life. (As an aside, this would have also let a jar contain multiple modules).
Ralph
> On Apr 24, 2017, at 2:38 PM, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
>
> Hm, I don't think a bridge implementation needs to fake a (API) module.
>
> Your client code requires the API module and no specific implementation. The implementations (including the bridge) export their specific packages to the API module (optionally with service provider for discovery).
>
> This is basically the same as with OSGi (only that modules allow friends easier). The runtime scope in maven would be for those modules which are not explicitely required but needed at runtime.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> From: jodastephen@gmail.com <jo...@gmail.com> on behalf of Stephen Colebourne <sc...@joda.org>
> Sent: Monday, April 24, 2017 1:42:33 PM
> To: Commons Developers List
> Subject: Re: [all] Java 9 module names
>
> On 24 April 2017 at 11:08, Jörg Schaible <jo...@bpm-inspire.com> wrote:
>> Stephen Colebourne wrote:
>>
>>> Sounds like you could use --add-modules to add the module separately
>>> from the command line, or add the module to the application's
>>> module-info rather than the libraries.
>>>
>>> In general, I suspect a library module-info.java should depend only on
>>> the other modules it really needs (eg. the API of slf4j), while
>>> something else, such as the application, adds the implementation
>>> module (eg. the SLF4J implementation).
>>
>> Which will create another chaos. Currently I can use the the xx-over-yy
>> artifacts to replace a hard coded dependency of an artifact if it is
>> required to embed it in a larger system.
>
> You still can. See my latest blog for the mental model you need:
> http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
>
> TL;DR, modules != artifacts. Depending on a module does not imply
> depending on exactly the same artifact that was used at compile time.
> Thus, the xx-over-yy jar files are still useful, provided they have
> the same module name as the module they are faking. See
> https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hm, I don't think a bridge implementation needs to fake a (API) module.
Your client code requires the API module and no specific implementation. The implementations (including the bridge) export their specific packages to the API module (optionally with service provider for discovery).
This is basically the same as with OSGi (only that modules allow friends easier). The runtime scope in maven would be for those modules which are not explicitely required but needed at runtime.
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: jodastephen@gmail.com <jo...@gmail.com> on behalf of Stephen Colebourne <sc...@joda.org>
Sent: Monday, April 24, 2017 1:42:33 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names
On 24 April 2017 at 11:08, Jörg Schaible <jo...@bpm-inspire.com> wrote:
> Stephen Colebourne wrote:
>
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>>
>> In general, I suspect a library module-info.java should depend only on
>> the other modules it really needs (eg. the API of slf4j), while
>> something else, such as the application, adds the implementation
>> module (eg. the SLF4J implementation).
>
> Which will create another chaos. Currently I can use the the xx-over-yy
> artifacts to replace a hard coded dependency of an artifact if it is
> required to embed it in a larger system.
You still can. See my latest blog for the mental model you need:
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
TL;DR, modules != artifacts. Depending on a module does not imply
depending on exactly the same artifact that was used at compile time.
Thus, the xx-over-yy jar files are still useful, provided they have
the same module name as the module they are faking. See
https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
On 24 April 2017 at 11:08, Jörg Schaible <jo...@bpm-inspire.com> wrote:
> Stephen Colebourne wrote:
>
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>>
>> In general, I suspect a library module-info.java should depend only on
>> the other modules it really needs (eg. the API of slf4j), while
>> something else, such as the application, adds the implementation
>> module (eg. the SLF4J implementation).
>
> Which will create another chaos. Currently I can use the the xx-over-yy
> artifacts to replace a hard coded dependency of an artifact if it is
> required to embed it in a larger system.
You still can. See my latest blog for the mental model you need:
http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html
TL;DR, modules != artifacts. Depending on a module does not imply
depending on exactly the same artifact that was used at compile time.
Thus, the xx-over-yy jar files are still useful, provided they have
the same module name as the module they are faking. See
https://jira.qos.ch/browse/SLF4J-408 for how slf4j needs tweaking.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Stephen Colebourne wrote:
> Sounds like you could use --add-modules to add the module separately
> from the command line, or add the module to the application's
> module-info rather than the libraries.
>
> In general, I suspect a library module-info.java should depend only on
> the other modules it really needs (eg. the API of slf4j), while
> something else, such as the application, adds the implementation
> module (eg. the SLF4J implementation).
Which will create another chaos. Currently I can use the the xx-over-yy
artifacts to replace a hard coded dependency of an artifact if it is
required to embed it in a larger system.
- J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
Sounds like you could use --add-modules to add the module separately
from the command line, or add the module to the application's
module-info rather than the libraries.
In general, I suspect a library module-info.java should depend only on
the other modules it really needs (eg. the API of slf4j), while
something else, such as the application, adds the implementation
module (eg. the SLF4J implementation).
Stephen
On 23 April 2017 at 18:14, Ralph Goers <ra...@dslextreme.com> wrote:
> Yes, I know it doesn't replace Maven, but in this case I have a dependency that is not required to compile but is required to run. It appears I have to convert my runtime scopes to compile in order to get the module to compile and build properly.
>
> That sucks.
>
> Sent from my iPhone
>
>> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <sc...@joda.org> wrote:
>>
>> I've never used that myself, but don't see anything similar.
>> Remember though that JPMS isn't trying to replace Maven. It just
>> intends there to be a reliable set of modules when running in the
>> platform.
>> Stephen
>>
>>
>>> On 23 April 2017 at 08:57, Ralph Goers <ra...@dslextreme.com> wrote:
>>> How does the module system support Maven’s runtime scope?
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <sc...@joda.org> wrote:
>>>>
>>>> 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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>>>>>
>>>>>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
Yes, I know it doesn't replace Maven, but in this case I have a dependency that is not required to compile but is required to run. It appears I have to convert my runtime scopes to compile in order to get the module to compile and build properly.
That sucks.
Sent from my iPhone
> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <sc...@joda.org> wrote:
>
> I've never used that myself, but don't see anything similar.
> Remember though that JPMS isn't trying to replace Maven. It just
> intends there to be a reliable set of modules when running in the
> platform.
> Stephen
>
>
>> On 23 April 2017 at 08:57, Ralph Goers <ra...@dslextreme.com> wrote:
>> How does the module system support Maven’s runtime scope?
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <sc...@joda.org> wrote:
>>>
>>> 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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>>>>
>>>>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
I've never used that myself, but don't see anything similar.
Remember though that JPMS isn't trying to replace Maven. It just
intends there to be a reliable set of modules when running in the
platform.
Stephen
On 23 April 2017 at 08:57, Ralph Goers <ra...@dslextreme.com> wrote:
> How does the module system support Maven’s runtime scope?
>
> Ralph
>
>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <sc...@joda.org> wrote:
>>
>> 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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>>>
>>>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
How does the module system support Maven’s runtime scope?
Ralph
> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <sc...@joda.org> wrote:
>
> 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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>>
>>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>>
>>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> 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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>>
>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <sc...@joda.org> 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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>>
>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
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 <ra...@dslextreme.com> 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 <sc...@joda.org> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <ra...@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 <ec...@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 <ra...@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 <sc...@joda.org> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> 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 <ra...@dslextreme.com> 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 <ec...@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 <ra...@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 <sc...@joda.org> wrote:
>>>>
>>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@dslextreme.com> 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 <ec...@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 <ra...@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 <sc...@joda.org> wrote:
>>>
>>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ec...@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 <ra...@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 <sc...@joda.org> wrote:
>>
>> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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 <ra...@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 <sc...@joda.org> wrote:
>
> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <sc...@joda.org> wrote:
>
> On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by Stephen Colebourne <sc...@joda.org>.
On 21 April 2017 at 13:59, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Java 9 module names
Posted by sebb <se...@gmail.com>.
On 21 April 2017 at 13:00, Stephen Colebourne <sc...@joda.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org