[all] Java 9 module names

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

Re: [all] Java 9 module names

Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

jodastephen
On 22 April 2017 at 09:00, Emmanuel Bourg <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Bernd Eckenfels
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: [hidden email] <[hidden email]> on behalf of Stephen Colebourne <[hidden email]>
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Robert Scholte
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  
<[hidden email]> 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: [hidden email] <[hidden email]> on behalf of Stephen  
> Colebourne <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Pascal Schumacher
In reply to this post by Emmanuel Bourg-3
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

garydgregory
On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Ralph Goers
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 <[hidden email]> wrote:
>
> On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> [hidden email] <mailto:[hidden email]>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] <mailto:[hidden email]> | [hidden email] <mailto:[hidden email]>
> 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>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

garydgregory
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" <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> > [hidden email] <mailto:[hidden email]>> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > E-Mail: [hidden email] <mailto:[hidden email]> |
> [hidden email] <mailto:[hidden email]>
> > 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>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Matt Sicker
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 <[hidden email]> 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" <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> > >
> > > On Sat, Apr 22, 2017 at 10:46 AM, Pascal Schumacher <
> > > [hidden email] <mailto:[hidden email]>> 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: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > >
> > > --
> > > E-Mail: [hidden email] <mailto:[hidden email]> |
> > [hidden email] <mailto:[hidden email]>
> > > 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 <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Ralph Goers
In reply to this post by jodastephen
How does the module system support Maven’s runtime scope?  

Ralph

> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <[hidden email]> 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 <[hidden email]> wrote:
>> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>>
>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>>
>>>> Some rules:
>>>> - Each module contains a set of packages, each of which must be
>>>> specified explicitly.
>>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>>> - No package can be in two modules
>>>>
>>>> Looking at the Javadoc here -
>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>> jar file has a separate set of packages it contains, with an obvious
>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>> dependencies.
>>>>
>>>> Possible modules:
>>>> - org.apache.logging.log4j
>>>> - org.apache.logging.log4j.core
>>>> - org.apache.logging.log4j.io
>>>> - org.apache.logging.log4j.taglib
>>>> - org.apache.logging.log4j.jcl
>>>> - org.apache.logging.log4j.jul
>>>> - org.apache.logging.log4j.flume.appender
>>>> - org.apache.logging.log4j.jmx.gui
>>>> - org.apache.logging.log4j.web
>>>> - org.apache.logging.log4j.nosql.appender
>>>>
>>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>>> * the logf4 v1 bridge probably can't be modularized
>>>>
>>>> Bernd has addressed the point about the need to export all packages
>>>> individually, allowing the modules above.
>>>>
>>>> Stephen
>>>>
>>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>>> I am having a hard time figuring out how Log4j is going to be able to support this.  The API itself is in org.apache.logging.log4j and some packages under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>
>>>>> Is there some reasonable way around this?
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>
>>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> wrote:
>>>>>>> What happens when there is a API break which necessitates a package name change?
>>>>>>> I assume that the module name will also need to change to the new super-package.
>>>>>>> e.g.
>>>>>>>
>>>>>>> Commons-Lang4
>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>> -> module org.apache.commons.lang4
>>>>>>
>>>>>> Yes, thats right.
>>>>>>
>>>>>>> AFAICT Commons generally has obvious and unique super-packages for
>>>>>>> each component.
>>>>>>> This should make it easier than for larger projects with lots of jars
>>>>>>> and potentially overlapping package names.
>>>>>>>
>>>>>>> However even Commons has some code that uses a different package structure.
>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>> This includes working examples that are included in the release.
>>>>>>> I guess that will have to change (which is probably a good idea anyway).
>>>>>>
>>>>>> Yes, as it stands, [net] would be a bad modular citizen, because it
>>>>>> exposes the "examples" package, and thus prevents any other module
>>>>>> from using that package. Just move it to
>>>>>> org.apache.commons.net.examples.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

jodastephen
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 <[hidden email]> wrote:

> How does the module system support Maven’s runtime scope?
>
> Ralph
>
>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <[hidden email]> 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 <[hidden email]> wrote:
>>> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>>>
>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>>>
>>>>> Some rules:
>>>>> - Each module contains a set of packages, each of which must be
>>>>> specified explicitly.
>>>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>>>> - No package can be in two modules
>>>>>
>>>>> Looking at the Javadoc here -
>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>> dependencies.
>>>>>
>>>>> Possible modules:
>>>>> - org.apache.logging.log4j
>>>>> - org.apache.logging.log4j.core
>>>>> - org.apache.logging.log4j.io
>>>>> - org.apache.logging.log4j.taglib
>>>>> - org.apache.logging.log4j.jcl
>>>>> - org.apache.logging.log4j.jul
>>>>> - org.apache.logging.log4j.flume.appender
>>>>> - org.apache.logging.log4j.jmx.gui
>>>>> - org.apache.logging.log4j.web
>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>
>>>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>
>>>>> Bernd has addressed the point about the need to export all packages
>>>>> individually, allowing the modules above.
>>>>>
>>>>> Stephen
>>>>>
>>>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>>>> I am having a hard time figuring out how Log4j is going to be able to support this.  The API itself is in org.apache.logging.log4j and some packages under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>>
>>>>>> Is there some reasonable way around this?
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> wrote:
>>>>>>>> What happens when there is a API break which necessitates a package name change?
>>>>>>>> I assume that the module name will also need to change to the new super-package.
>>>>>>>> e.g.
>>>>>>>>
>>>>>>>> Commons-Lang4
>>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>>> -> module org.apache.commons.lang4
>>>>>>>
>>>>>>> Yes, thats right.
>>>>>>>
>>>>>>>> AFAICT Commons generally has obvious and unique super-packages for
>>>>>>>> each component.
>>>>>>>> This should make it easier than for larger projects with lots of jars
>>>>>>>> and potentially overlapping package names.
>>>>>>>>
>>>>>>>> However even Commons has some code that uses a different package structure.
>>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>>> This includes working examples that are included in the release.
>>>>>>>> I guess that will have to change (which is probably a good idea anyway).
>>>>>>>
>>>>>>> Yes, as it stands, [net] would be a bad modular citizen, because it
>>>>>>> exposes the "examples" package, and thus prevents any other module
>>>>>>> from using that package. Just move it to
>>>>>>> org.apache.commons.net.examples.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Ralph Goers
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 <[hidden email]> 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 <[hidden email]> wrote:
>> How does the module system support Maven’s runtime scope?
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <[hidden email]> 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 <[hidden email]> wrote:
>>>> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>>>>
>>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>
>>>>>> Some rules:
>>>>>> - Each module contains a set of packages, each of which must be
>>>>>> specified explicitly.
>>>>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>>>>> - No package can be in two modules
>>>>>>
>>>>>> Looking at the Javadoc here -
>>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>>> dependencies.
>>>>>>
>>>>>> Possible modules:
>>>>>> - org.apache.logging.log4j
>>>>>> - org.apache.logging.log4j.core
>>>>>> - org.apache.logging.log4j.io
>>>>>> - org.apache.logging.log4j.taglib
>>>>>> - org.apache.logging.log4j.jcl
>>>>>> - org.apache.logging.log4j.jul
>>>>>> - org.apache.logging.log4j.flume.appender
>>>>>> - org.apache.logging.log4j.jmx.gui
>>>>>> - org.apache.logging.log4j.web
>>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>>
>>>>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>>
>>>>>> Bernd has addressed the point about the need to export all packages
>>>>>> individually, allowing the modules above.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>>>>> I am having a hard time figuring out how Log4j is going to be able to support this.  The API itself is in org.apache.logging.log4j and some packages under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>>>
>>>>>>> Is there some reasonable way around this?
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> wrote:
>>>>>>>>> What happens when there is a API break which necessitates a package name change?
>>>>>>>>> I assume that the module name will also need to change to the new super-package.
>>>>>>>>> e.g.
>>>>>>>>>
>>>>>>>>> Commons-Lang4
>>>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>>>> -> module org.apache.commons.lang4
>>>>>>>>
>>>>>>>> Yes, thats right.
>>>>>>>>
>>>>>>>>> AFAICT Commons generally has obvious and unique super-packages for
>>>>>>>>> each component.
>>>>>>>>> This should make it easier than for larger projects with lots of jars
>>>>>>>>> and potentially overlapping package names.
>>>>>>>>>
>>>>>>>>> However even Commons has some code that uses a different package structure.
>>>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>>>> This includes working examples that are included in the release.
>>>>>>>>> I guess that will have to change (which is probably a good idea anyway).
>>>>>>>>
>>>>>>>> Yes, as it stands, [net] would be a bad modular citizen, because it
>>>>>>>> exposes the "examples" package, and thus prevents any other module
>>>>>>>> from using that package. Just move it to
>>>>>>>> org.apache.commons.net.examples.
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Bernd Eckenfels
Hm why is that? What step in your compile would need the runtime module?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Ralph Goers <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> wrote:
>> How does the module system support Maven’s runtime scope?
>>
>> Ralph
>>
>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <[hidden email]> 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 <[hidden email]> wrote:
>>>> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>>>>
>>>> Ralph
>>>>
>>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>>>>
>>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>
>>>>>> Some rules:
>>>>>> - Each module contains a set of packages, each of which must be
>>>>>> specified explicitly.
>>>>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>>>>> - No package can be in two modules
>>>>>>
>>>>>> Looking at the Javadoc here -
>>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>>> dependencies.
>>>>>>
>>>>>> Possible modules:
>>>>>> - org.apache.logging.log4j
>>>>>> - org.apache.logging.log4j.core
>>>>>> - org.apache.logging.log4j.io
>>>>>> - org.apache.logging.log4j.taglib
>>>>>> - org.apache.logging.log4j.jcl
>>>>>> - org.apache.logging.log4j.jul
>>>>>> - org.apache.logging.log4j.flume.appender
>>>>>> - org.apache.logging.log4j.jmx.gui
>>>>>> - org.apache.logging.log4j.web
>>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>>
>>>>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>>
>>>>>> Bernd has addressed the point about the need to export all packages
>>>>>> individually, allowing the modules above.
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>>>>> I am having a hard time figuring out how Log4j is going to be able to support this.  The API itself is in org.apache.logging.log4j and some packages under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>>>
>>>>>>> Is there some reasonable way around this?
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> wrote:
>>>>>>>>> What happens when there is a API break which necessitates a package name change?
>>>>>>>>> I assume that the module name will also need to change to the new super-package.
>>>>>>>>> e.g.
>>>>>>>>>
>>>>>>>>> Commons-Lang4
>>>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>>>> -> module org.apache.commons.lang4
>>>>>>>>
>>>>>>>> Yes, thats right.
>>>>>>>>
>>>>>>>>> AFAICT Commons generally has obvious and unique super-packages for
>>>>>>>>> each component.
>>>>>>>>> This should make it easier than for larger projects with lots of jars
>>>>>>>>> and potentially overlapping package names.
>>>>>>>>>
>>>>>>>>> However even Commons has some code that uses a different package structure.
>>>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>>>> This includes working examples that are included in the release.
>>>>>>>>> I guess that will have to change (which is probably a good idea anyway).
>>>>>>>>
>>>>>>>> Yes, as it stands, [net] would be a bad modular citizen, because it
>>>>>>>> exposes the "examples" package, and thus prevents any other module
>>>>>>>> from using that package. Just move it to
>>>>>>>> org.apache.commons.net.examples.
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

jodastephen
In reply to this post by Ralph Goers
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> How does the module system support Maven’s runtime scope?
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <[hidden email]> 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 <[hidden email]> wrote:
>>>>> On to the next question - which I apologize for asking as it may not apply to Commons.  Log4j has lots of optional components to support lots of third party stuff (some ASF projects and some not). How do we handle things that haven’t yet been modularized? Normally I would expect to have requires directives.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <[hidden email]> wrote:
>>>>>>
>>>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>>
>>>>>>> Some rules:
>>>>>>> - Each module contains a set of packages, each of which must be
>>>>>>> specified explicitly.
>>>>>>> - Modules depend on other modules, but must not form a cycle of dependencies.
>>>>>>> - No package can be in two modules
>>>>>>>
>>>>>>> Looking at the Javadoc here -
>>>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each
>>>>>>> jar file has a separate set of packages it contains, with an obvious
>>>>>>> super-package for each jar file*. Furthermore, the super-packages of
>>>>>>> the jar files do not clash, so I think you are fine in naming terms.
>>>>>>> What I can't be sure from the Javadoc is whether there is a cycle of
>>>>>>> dependencies.
>>>>>>>
>>>>>>> Possible modules:
>>>>>>> - org.apache.logging.log4j
>>>>>>> - org.apache.logging.log4j.core
>>>>>>> - org.apache.logging.log4j.io
>>>>>>> - org.apache.logging.log4j.taglib
>>>>>>> - org.apache.logging.log4j.jcl
>>>>>>> - org.apache.logging.log4j.jul
>>>>>>> - org.apache.logging.log4j.flume.appender
>>>>>>> - org.apache.logging.log4j.jmx.gui
>>>>>>> - org.apache.logging.log4j.web
>>>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>>>
>>>>>>> * the slf4j bridge is problematic, but is being addressed by changes in slf4j.
>>>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>>>
>>>>>>> Bernd has addressed the point about the need to export all packages
>>>>>>> individually, allowing the modules above.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>> On 21 April 2017 at 21:34, Ralph Goers <[hidden email]> wrote:
>>>>>>>> I am having a hard time figuring out how Log4j is going to be able to support this.  The API itself is in org.apache.logging.log4j and some packages under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>>>>
>>>>>>>> Is there some reasonable way around this?
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> On 21 April 2017 at 13:59, sebb <[hidden email]> wrote:
>>>>>>>>>> What happens when there is a API break which necessitates a package name change?
>>>>>>>>>> I assume that the module name will also need to change to the new super-package.
>>>>>>>>>> e.g.
>>>>>>>>>>
>>>>>>>>>> Commons-Lang4
>>>>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>>>>> -> module org.apache.commons.lang4
>>>>>>>>>
>>>>>>>>> Yes, thats right.
>>>>>>>>>
>>>>>>>>>> AFAICT Commons generally has obvious and unique super-packages for
>>>>>>>>>> each component.
>>>>>>>>>> This should make it easier than for larger projects with lots of jars
>>>>>>>>>> and potentially overlapping package names.
>>>>>>>>>>
>>>>>>>>>> However even Commons has some code that uses a different package structure.
>>>>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>>>>> This includes working examples that are included in the release.
>>>>>>>>>> I guess that will have to change (which is probably a good idea anyway).
>>>>>>>>>
>>>>>>>>> Yes, as it stands, [net] would be a bad modular citizen, because it
>>>>>>>>> exposes the "examples" package, and thus prevents any other module
>>>>>>>>> from using that package. Just move it to
>>>>>>>>> org.apache.commons.net.examples.
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Jörg Schaible-5
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

jodastephen
On 24 April 2017 at 11:08, Jörg Schaible <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Bernd Eckenfels
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: [hidden email] <[hidden email]> on behalf of Stephen Colebourne <[hidden email]>
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Java 9 module names

Ralph Goers
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 <[hidden email]> 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: [hidden email] <[hidden email]> on behalf of Stephen Colebourne <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



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

12