Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 18:14, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 1:11 PM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins > > wrote: > >> > >> > >> > >>> On Apr 9, 2019, at 11:57 AM, sebb wrote: > >>> > >>> On Tue, 9 Apr 2019 at 16:53,

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 1:11 PM, sebb wrote: > > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins > wrote: >> >> >> >>> On Apr 9, 2019, at 11:57 AM, sebb wrote: >>> >>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann >>> wrote: On Tue, Apr 9, 2019 at 3:51 PM

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 17:06, Rob Tompkins wrote: > > > > > On Apr 9, 2019, at 11:57 AM, sebb wrote: > > > > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann > > wrote: > >> > >> On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > >> > >>> We already have a process for ensuring that Maven coords and

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 11:57 AM, sebb wrote: > > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann > wrote: >> >> On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: >> >>> We already have a process for ensuring that Maven coords and package >>> names are changed when API breaks. >>> Do we really want to

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > > > We already have a process for ensuring that Maven coords and package > > names are changed when API breaks. > > Do we really want to have yet another name that has to be maintained? > >

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 3:51 PM sebb wrote: > We already have a process for ensuring that Maven coords and package > names are changed when API breaks. > Do we really want to have yet another name that has to be maintained? What's the alternative? > Being able to define the module name

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 2:43 PM sebb wrote: > > > Unless I am misunderstanding this, the property value won't be checked > > to see if i is changed when an incompatible versioni s released. > > True, but that applies in either case, as soon

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 2:43 PM sebb wrote: > Unless I am misunderstanding this, the property value won't be checked > to see if i is changed when an incompatible versioni s released. True, but that applies in either case, as soon as we have module names, doesn't it? So, I'd like to keep this

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Le mar. 9 avr. 2019 à 14:11, Rob Tompkins a écrit : > > > > > On Apr 9, 2019, at 7:21 AM, Gilles Sadowski wrote: > > > > Le mar. 9 avr. 2019 à 13:03, sebb > > a écrit : > >> > >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > >>> > [...] > > > > $

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 12:43 PM Gilles Sadowski wrote: > ${commons.automatic.module.name} Fine with me. > Then the release plugin could be enhanced (?) so that it would check > whether the variable has been defined for each JAR to be created (and > fail the build otherwise). As already

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann wrote: > > On Tue, Apr 9, 2019 at 10:48 AM John Patrick wrote: > > > > As commons-lang3 has the module name org.apache.commons.lang3, not > > commons-lang3 which is the artifactId, because "-" is invalid in a > > real module name and they realised

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 2:37 PM Gary Gregory wrote: > Can't we do this in a more lightweight manner in Checkstyle or in our build > Maven plugin? I'll leave the former idea to you, and the latter to Rob. Myself, I don't know in both cases. But I am open. Jochen

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 1:22 PM Gilles Sadowski wrote: > From > https://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html > ---CUT--- > Module names must be valid Java identifiers! E.g. no Java keywords, no > dashes, no... > ---CUT--- Wasn't aware of that, thanks for the hint. Jochen

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 8:32 AM Jochen Wiedmann wrote: > On Tue, Apr 9, 2019 at 10:48 AM John Patrick > wrote: > > > > As commons-lang3 has the module name org.apache.commons.lang3, not > > commons-lang3 which is the artifactId, because "-" is invalid in a > > real module name and they realised

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 10:48 AM John Patrick wrote: > As commons-lang3 has the module name org.apache.commons.lang3, not > commons-lang3 which is the artifactId, because "-" is invalid in a > real module name and they realised this when starting to support jpms. Commons-lang, and others, can

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, Apr 9, 2019 at 9:54 AM sebb wrote: > > I have studied EMAIL-186. My impression is, that all commons jar files > > should provide a fixed module name, rather than trusting in the choice > > of the JDK. Thus, it seems best to handle this in parent. So, here's > > my proposal for a change.

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> On Apr 9, 2019, at 7:21 AM, Gilles Sadowski wrote: > > Le mar. 9 avr. 2019 à 13:03, sebb > a écrit : >> >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: >>> [...] > > $ git diff pom.xml > diff --git a/pom.xml b/pom.xml > index

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Le mar. 9 avr. 2019 à 13:03, sebb a écrit : > > On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > > > > > [...] > > > > > > > > $ git diff pom.xml > > > > diff --git a/pom.xml b/pom.xml > > > > index 2612dd6..54a88e4 100644 > > > > --- a/pom.xml > > > > +++ b/pom.xml > > > > @@ -570,6 +570,7

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski wrote: > > > [...] > > > > > > $ git diff pom.xml > > > diff --git a/pom.xml b/pom.xml > > > index 2612dd6..54a88e4 100644 > > > --- a/pom.xml > > > +++ b/pom.xml > > > @@ -570,6 +570,7 @@ > > > > > > ${implementation.build} > > >

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

> [...] > > > > $ git diff pom.xml > > diff --git a/pom.xml b/pom.xml > > index 2612dd6..54a88e4 100644 > > --- a/pom.xml > > +++ b/pom.xml > > @@ -570,6 +570,7 @@ > > > > ${implementation.build} > > > > ${maven.compiler.source} > > > >

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 08:54, sebb wrote: > > On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann > wrote: > > > > Hi, > > > > I have studied EMAIL-186. My impression is, that all commons jar files > > should provide a fixed module name, rather than trusting in the choice > > of the JDK. Thus, it seems

Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann wrote: > > Hi, > > I have studied EMAIL-186. My impression is, that all commons jar files > should provide a fixed module name, rather than trusting in the choice > of the JDK. Thus, it seems best to handle this in parent. So, here's > my proposal for

***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Hi, I have studied EMAIL-186. My impression is, that all commons jar files should provide a fixed module name, rather than trusting in the choice of the JDK. Thus, it seems best to handle this in parent. So, here's my proposal for a change. Please, let me know, what you think of that, so that I