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

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

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

jochen-2
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 can either fix it, op proceed with committing.

Thanks,

Jochen


$ 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>${implementation.build}</Implementation-Build>
               <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
               <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
+              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
             </manifestEntries>
           </archive>
         </configuration>
@@ -1608,6 +1609,9 @@
     <maven.compiler.source>1.3</maven.compiler.source>
     <maven.compiler.target>1.3</maven.compiler.target>

+    <!-- Module name for Java 9, and beyond -->
+    <commons.module.name>${project.artifactId}</commons.module.name>
+
     <!-- compiler and surefire plugin settings for "java" profiles -->
     <commons.compiler.fork>false</commons.compiler.fork>
     <commons.compiler.compilerVersion />

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann <[hidden email]> 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 a change. Please, let me know, what you think of that,
> so that I can either fix it, op proceed with committing.

What exactly does 'fixed' mean in this context?

If it is supposed to be tied to API compatibility, then strictly
speaking it needs the group-id as well.

If there is only supposed to be one module name regardless of API
compatibility, then artifact-id won't do as it is not immutable.

> Thanks,
>
> Jochen
>
>
> $ 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>${implementation.build}</Implementation-Build>
>                <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
>                <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
>              </manifestEntries>
>            </archive>
>          </configuration>
> @@ -1608,6 +1609,9 @@
>      <maven.compiler.source>1.3</maven.compiler.source>
>      <maven.compiler.target>1.3</maven.compiler.target>
>
> +    <!-- Module name for Java 9, and beyond -->
> +    <commons.module.name>${project.artifactId}</commons.module.name>
> +
>      <!-- compiler and surefire plugin settings for "java" profiles -->
>      <commons.compiler.fork>false</commons.compiler.fork>
>      <commons.compiler.compilerVersion />
>
> ---------------------------------------------------------------------
> 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: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

John Patrick
On Tue, 9 Apr 2019 at 08:54, sebb <[hidden email]> wrote:

>
> On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann <[hidden email]> 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 a change. Please, let me know, what you think of that,
> > so that I can either fix it, op proceed with committing.
>
> What exactly does 'fixed' mean in this context?
>
> If it is supposed to be tied to API compatibility, then strictly
> speaking it needs the group-id as well.
>
> If there is only supposed to be one module name regardless of API
> compatibility, then artifact-id won't do as it is not immutable.
>
> > Thanks,
> >
> > Jochen
> >
> >
> > $ 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>${implementation.build}</Implementation-Build>
> >                <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
> >                <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> > +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
> >              </manifestEntries>
> >            </archive>
> >          </configuration>
> > @@ -1608,6 +1609,9 @@
> >      <maven.compiler.source>1.3</maven.compiler.source>
> >      <maven.compiler.target>1.3</maven.compiler.target>
> >
> > +    <!-- Module name for Java 9, and beyond -->
> > +    <commons.module.name>${project.artifactId}</commons.module.name>
> > +
> >      <!-- compiler and surefire plugin settings for "java" profiles -->
> >      <commons.compiler.fork>false</commons.compiler.fork>
> >      <commons.compiler.compilerVersion />
> >
> > ---------------------------------------------------------------------
> > 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]
>

Really like this change, but as a consumer of the jars generated by
this parent patch, could the default not be the artifactId, as it will
just mean 2 migrations.

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.

So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
it's very very clear.

John

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

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
In reply to this post by sebb-2-2
> [...]
> >
> > $ 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>${implementation.build}</Implementation-Build>
> >                <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
> >                <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> > +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>

${commons.automatic.module.name}

> >              </manifestEntries>
> >            </archive>
> >          </configuration>
> > @@ -1608,6 +1609,9 @@
> >      <maven.compiler.source>1.3</maven.compiler.source>
> >      <maven.compiler.target>1.3</maven.compiler.target>
> >
> > +    <!-- Module name for Java 9, and beyond -->
> > +    <commons.module.name>${project.artifactId}</commons.module.name>

No default should be defined (to avoid the risk of creating incompatible
but identically named modules).
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).

Gilles

> > +
> >      <!-- compiler and surefire plugin settings for "java" profiles -->
> >      <commons.compiler.fork>false</commons.compiler.fork>
> >      <commons.compiler.compilerVersion />
> >

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <[hidden email]> 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>${implementation.build}</Implementation-Build>
> > >                <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
> > >                <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> > > +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
>
> ${commons.automatic.module.name}
>
> > >              </manifestEntries>
> > >            </archive>
> > >          </configuration>
> > > @@ -1608,6 +1609,9 @@
> > >      <maven.compiler.source>1.3</maven.compiler.source>
> > >      <maven.compiler.target>1.3</maven.compiler.target>
> > >
> > > +    <!-- Module name for Java 9, and beyond -->
> > > +    <commons.module.name>${project.artifactId}</commons.module.name>
>
> No default should be defined (to avoid the risk of creating incompatible
> but identically named modules).

Surely that *should* be solved by using groupId + artifactId?
We change one or the other when releasing an incompatible module.

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

But how would that ensure incompatible modules were given different names?

> Gilles
>
> > > +
> > >      <!-- compiler and surefire plugin settings for "java" profiles -->
> > >      <commons.compiler.fork>false</commons.compiler.fork>
> > >      <commons.compiler.compilerVersion />
> > >
>
> ---------------------------------------------------------------------
> 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: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Gilles Sadowski-2
Le mar. 9 avr. 2019 à 13:03, sebb <[hidden email]> a écrit :

>
> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <[hidden email]> 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>${implementation.build}</Implementation-Build>
> > > >                <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
> > > >                <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> > > > +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
> >
> > ${commons.automatic.module.name}
> >
> > > >              </manifestEntries>
> > > >            </archive>
> > > >          </configuration>
> > > > @@ -1608,6 +1609,9 @@
> > > >      <maven.compiler.source>1.3</maven.compiler.source>
> > > >      <maven.compiler.target>1.3</maven.compiler.target>
> > > >
> > > > +    <!-- Module name for Java 9, and beyond -->
> > > > +    <commons.module.name>${project.artifactId}</commons.module.name>
> >
> > No default should be defined (to avoid the risk of creating incompatible
> > but identically named modules).
>
> Surely that *should* be solved by using groupId + artifactId?

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

> We change one or the other when releasing an incompatible module.
>
> > 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).
>
> But how would that ensure incompatible modules were given different names?

It would not.
[IIUC, same issue with OSGI config.]

>
> > Gilles
> >
> > > > +
> > > >      <!-- compiler and surefire plugin settings for "java" profiles -->
> > > >      <commons.compiler.fork>false</commons.compiler.fork>
> > > >      <commons.compiler.compilerVersion />
> > > >
> >

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

Reply | Threaded
Open this post in threaded view
|

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

Rob Tompkins


> On Apr 9, 2019, at 7:21 AM, Gilles Sadowski <[hidden email]> wrote:
>
> Le mar. 9 avr. 2019 à 13:03, sebb <[hidden email] <mailto:[hidden email]>> a écrit :
>>
>> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <[hidden email]> 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>${implementation.build}</Implementation-Build>
>>>>>               <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
>>>>>               <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
>>>>> +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
>>>
>>> ${commons.automatic.module.name}
>>>
>>>>>             </manifestEntries>
>>>>>           </archive>
>>>>>         </configuration>
>>>>> @@ -1608,6 +1609,9 @@
>>>>>     <maven.compiler.source>1.3</maven.compiler.source>
>>>>>     <maven.compiler.target>1.3</maven.compiler.target>
>>>>>
>>>>> +    <!-- Module name for Java 9, and beyond -->
>>>>> +    <commons.module.name>${project.artifactId}</commons.module.name>
>>>
>>> No default should be defined (to avoid the risk of creating incompatible
>>> but identically named modules).
>>
>> Surely that *should* be solved by using groupId + artifactId?
>
> From
>    https://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html <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---
>
>> We change one or the other when releasing an incompatible module.
>>
>>> 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).
>>
>> But how would that ensure incompatible modules were given different names?
>
> It would not.
> [IIUC, same issue with OSGI config.]

If it’s the same issue as OSGI, should we not then use the same value as we do with OSGI, which we already have?

>
>>
>>> Gilles
>>>
>>>>> +
>>>>>     <!-- compiler and surefire plugin settings for "java" profiles -->
>>>>>     <commons.compiler.fork>false</commons.compiler.fork>
>>>>>     <commons.compiler.compilerVersion />
>>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

jochen-2
In reply to this post by sebb-2-2
On Tue, Apr 9, 2019 at 9:54 AM sebb <[hidden email]> 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. Please, let me know, what you think of that,
> > so that I can either fix it, op proceed with committing.
>
> What exactly does 'fixed' mean in this context?

That I am open for adopting suggestions, etc.

> If it is supposed to be tied to API compatibility, then strictly
> speaking it needs the group-id as well.
>
> If there is only supposed to be one module name regardless of API
> compatibility, then artifact-id won't do as it is not immutable.

That's why a component can set the property commons.module.name in
their own POM.

Jochen

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

Reply | Threaded
Open this post in threaded view
|

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

jochen-2
In reply to this post by John Patrick
On Tue, Apr 9, 2019 at 10:48 AM John Patrick <[hidden email]> 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 fix this by overriding the property value.

> So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
> it's very very clear.

I think we can do better than that: Use the maven-antrun plugin (or
the groovy-maven-plugin, or whatever) to check, whether the propery
value is given. If not, abort the build. That way, components will
have that property value as soon as they adopt the respective version
of commons-parent.

Jochen

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

Reply | Threaded
Open this post in threaded view
|

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

jochen-2
In reply to this post by Gilles Sadowski-2
On Tue, Apr 9, 2019 at 12:43 PM Gilles Sadowski <[hidden email]> 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 written: We can use the maven-antrun-plugin, the
groovy-maven-plugin, or something similar to check that.

Jochen

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

Reply | Threaded
Open this post in threaded view
|

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

garydgregory
In reply to this post by jochen-2
On Tue, Apr 9, 2019 at 8:32 AM Jochen Wiedmann <[hidden email]>
wrote:

> On Tue, Apr 9, 2019 at 10:48 AM John Patrick <[hidden email]>
> 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 fix this by overriding the property value.
>
> > So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
> > it's very very clear.
>
> I think we can do better than that: Use the maven-antrun plugin (or
> the groovy-maven-plugin, or whatever) to check, whether the propery
> value is given. If not, abort the build. That way, components will
> have that property value as soon as they adopt the respective version
> of commons-parent.
>

Can't we do this in a more lightweight manner in Checkstyle or in our build
Maven plugin?

Gary


> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

jochen-2
In reply to this post by Gilles Sadowski-2
On Tue, Apr 9, 2019 at 1:22 PM Gilles Sadowski <[hidden email]> 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

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

Reply | Threaded
Open this post in threaded view
|

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

jochen-2
In reply to this post by garydgregory
On Tue, Apr 9, 2019 at 2:37 PM Gary Gregory <[hidden email]> 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

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

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski-2
In reply to this post by Rob Tompkins
Le mar. 9 avr. 2019 à 14:11, Rob Tompkins <[hidden email]> a écrit :

>
>
>
> > On Apr 9, 2019, at 7:21 AM, Gilles Sadowski <[hidden email]> wrote:
> >
> > Le mar. 9 avr. 2019 à 13:03, sebb <[hidden email] <mailto:[hidden email]>> a écrit :
> >>
> >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <[hidden email]> 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>${implementation.build}</Implementation-Build>
> >>>>>               <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
> >>>>>               <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
> >>>>> +              <Automatic-Module-Name>${commons.module.name}</Automatic-Module-Name>
> >>>
> >>> ${commons.automatic.module.name}
> >>>
> >>>>>             </manifestEntries>
> >>>>>           </archive>
> >>>>>         </configuration>
> >>>>> @@ -1608,6 +1609,9 @@
> >>>>>     <maven.compiler.source>1.3</maven.compiler.source>
> >>>>>     <maven.compiler.target>1.3</maven.compiler.target>
> >>>>>
> >>>>> +    <!-- Module name for Java 9, and beyond -->
> >>>>> +    <commons.module.name>${project.artifactId}</commons.module.name>
> >>>
> >>> No default should be defined (to avoid the risk of creating incompatible
> >>> but identically named modules).
> >>
> >> Surely that *should* be solved by using groupId + artifactId?
> >
> > From
> >    https://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html <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---
> >
> >> We change one or the other when releasing an incompatible module.
> >>
> >>> 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).
> >>
> >> But how would that ensure incompatible modules were given different names?
> >
> > It would not.
> > [IIUC, same issue with OSGI config.]
>
> If it’s the same issue as OSGI, should we not then use the same value as we do with OSGI, which we already have?

The requirements/limitations are not necessarily the same.
Also, the parent cannot know the specifics of each component, in
particular for modular projects.

Gilles

> >>>
> >>>>> +
> >>>>>     <!-- compiler and surefire plugin settings for "java" profiles -->
> >>>>>     <commons.compiler.fork>false</commons.compiler.fork>
> >>>>>     <commons.compiler.compilerVersion />
> >>>>>
> >>>
> >

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
In reply to this post by jochen-2
On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann <[hidden email]> wrote:

>
> On Tue, Apr 9, 2019 at 10:48 AM John Patrick <[hidden email]> 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 fix this by overriding the property value.
>
> > So could the default be something like OVERRIDE_PER_RELEASED_JAR, so
> > it's very very clear.
>
> I think we can do better than that: Use the maven-antrun plugin (or
> the groovy-maven-plugin, or whatever) to check, whether the propery
> value is given. If not, abort the build. That way, components will
> have that property value as soon as they adopt the respective version
> of commons-parent.

Unless I am misunderstanding this, the property value won't be checked
to see if i is changed when an incompatible versioni s released.

i.e. another item people need to remember to change when an
incompatible version is released.

However, if the module name is derived from gid+aid (with invalid
characters suitably replaced), it will happen automatically.

> Jochen
>
> ---------------------------------------------------------------------
> 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: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

jochen-2
On Tue, Apr 9, 2019 at 2:43 PM sebb <[hidden email]> 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 out of the current
discussion, which is (IMO) about how we implement the module name.

Jochen

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann <[hidden email]> wrote:
>
> On Tue, Apr 9, 2019 at 2:43 PM sebb <[hidden email]> 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?

Not sure which cases you are referring to.

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?

> So, I'd like to keep this out of the current
> discussion, which is (IMO) about how we implement the module name.

But what are we trying to achieve here?

Being able to define the module name independently is all very well,
but it does not solve the problem of ensuring that the module name is
correct, and remains correct when code is updated.

> Jochen
>
> ---------------------------------------------------------------------
> 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: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

jochen-2
On Tue, Apr 9, 2019 at 3:51 PM sebb <[hidden email]> 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 independently is all very well,
> but it does not solve the problem of ensuring that the module name is
> correct, and remains correct when code is updated.

That is, IMO, a problem, which can (and will) be solved later.

Jochen

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

Reply | Threaded
Open this post in threaded view
|

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

sebb-2-2
On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <[hidden email]> wrote:
>
> On Tue, Apr 9, 2019 at 3:51 PM sebb <[hidden email]> 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?

As I already wrote, use the gid + aid to generate a suitable name.

>
> > Being able to define the module name independently is all very well,
> > but it does not solve the problem of ensuring that the module name is
> > correct, and remains correct when code is updated.
>
> That is, IMO, a problem, which can (and will) be solved later.

Which may involve reverting the work already done.

> Jochen
>
> ---------------------------------------------------------------------
> 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: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name

Rob Tompkins


> On Apr 9, 2019, at 11:57 AM, sebb <[hidden email]> wrote:
>
> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <[hidden email]> wrote:
>>
>> On Tue, Apr 9, 2019 at 3:51 PM sebb <[hidden email]> 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?
>
> As I already wrote, use the gid + aid to generate a suitable name.

We already do this for OSGI here’s the [lang] example: https://github.com/apache/commons-lang/blob/master/pom.xml#L581 <https://github.com/apache/commons-lang/blob/master/pom.xml#L581> combined with https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>



>
>>
>>> Being able to define the module name independently is all very well,
>>> but it does not solve the problem of ensuring that the module name is
>>> correct, and remains correct when code is updated.
>>
>> That is, IMO, a problem, which can (and will) be solved later.
>
> Which may involve reverting the work already done.
>
>> Jochen
>>
>> ---------------------------------------------------------------------
>> 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