You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2019/04/09 06:58:15 UTC
***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 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 18:14, Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> > On Apr 9, 2019, at 1:11 PM, sebb <se...@gmail.com> wrote:
> >
> > On Tue, 9 Apr 2019 at 17:06, Rob Tompkins <chtompki@gmail.com <ma...@gmail.com>> wrote:
> >>
> >>
> >>
> >>> On Apr 9, 2019, at 11:57 AM, sebb <se...@gmail.com> wrote:
> >>>
> >>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jo...@gmail.com> wrote:
> >>>>
> >>>> On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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> <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> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>>
> >
> > I think 'org.apache.commons' should probably be: ${project.groupId} in CP.
> > Otherwise projects that are still on a different groupId may get a
> > duplicate conflicting name if they move to o.a.c as the groupId.
>
> I’m a +1 to that idea, but it is worth noting that we do have antiquated groupId’s that look like “commons-<packageId>” in the project. They would have to be changed at their next release.
It's those components that I was thinking of.
But if they have already been released with the o.a.c name then it's
probably too late.
If they currently have an OSGI name starting with o.a.c, then that
won't currently change if they change groupId only.
Any such components would also need to change artifactID and package name.
> -Rob
>
> >
> >>
> >>
> >>
> >>>
> >>>>
> >>>>> 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: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> > For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Rob Tompkins <ch...@gmail.com>.
> On Apr 9, 2019, at 1:11 PM, sebb <se...@gmail.com> wrote:
>
> On Tue, 9 Apr 2019 at 17:06, Rob Tompkins <chtompki@gmail.com <ma...@gmail.com>> wrote:
>>
>>
>>
>>> On Apr 9, 2019, at 11:57 AM, sebb <se...@gmail.com> wrote:
>>>
>>> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jo...@gmail.com> wrote:
>>>>
>>>> On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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> <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> <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743 <https://github.com/apache/commons-parent/blob/master/pom.xml#L1743>>
>
> I think 'org.apache.commons' should probably be: ${project.groupId} in CP.
> Otherwise projects that are still on a different groupId may get a
> duplicate conflicting name if they move to o.a.c as the groupId.
I’m a +1 to that idea, but it is worth noting that we do have antiquated groupId’s that look like “commons-<packageId>” in the project. They would have to be changed at their next release.
-Rob
>
>>
>>
>>
>>>
>>>>
>>>>> 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: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 17:06, Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
> > On Apr 9, 2019, at 11:57 AM, sebb <se...@gmail.com> wrote:
> >
> > On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jo...@gmail.com> wrote:
> >>
> >> On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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>
I think 'org.apache.commons' should probably be: ${project.groupId} in CP.
Otherwise projects that are still on a different groupId may get a
duplicate conflicting name if they move to o.a.c as the groupId.
>
>
>
> >
> >>
> >>> 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: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Rob Tompkins <ch...@gmail.com>.
> On Apr 9, 2019, at 11:57 AM, sebb <se...@gmail.com> wrote:
>
> On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jo...@gmail.com> wrote:
>>
>> On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 16:53, Jochen Wiedmann <jo...@gmail.com> wrote:
>
> On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 3:51 PM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 13:54, Jochen Wiedmann <jo...@gmail.com> wrote:
>
> On Tue, Apr 9, 2019 at 2:43 PM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 2:43 PM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 13:32, Jochen Wiedmann <jo...@gmail.com> wrote:
>
> On Tue, Apr 9, 2019 at 10:48 AM John Patrick <nh...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 2:37 PM Gary Gregory <ga...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Apr 9, 2019 at 8:32 AM Jochen Wiedmann <jo...@gmail.com>
wrote:
> On Tue, Apr 9, 2019 at 10:48 AM John Patrick <nh...@gmail.com>
> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 10:48 AM John Patrick <nh...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by John Patrick <nh...@gmail.com>.
On Tue, 9 Apr 2019 at 08:54, sebb <se...@gmail.com> wrote:
>
> On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann <jo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 12:43 PM Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mar. 9 avr. 2019 à 14:11, Rob Tompkins <ch...@gmail.com> a écrit :
>
>
>
> > On Apr 9, 2019, at 7:21 AM, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Le mar. 9 avr. 2019 à 13:03, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
> >>
> >> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Rob Tompkins <ch...@gmail.com>.
> On Apr 9, 2019, at 7:21 AM, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Le mar. 9 avr. 2019 à 13:03, sebb <sebbaz@gmail.com <ma...@gmail.com>> a écrit :
>>
>> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 1:22 PM Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mar. 9 avr. 2019 à 13:03, sebb <se...@gmail.com> a écrit :
>
> On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 11:43, Gilles Sadowski <gi...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Gilles Sadowski <gi...@gmail.com>.
> [...]
> >
> > $ 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 9, 2019 at 9:54 AM sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: ***UNCHECKED*** [parent] Introducing Automatic-Module-Name
Posted by sebb <se...@gmail.com>.
On Tue, 9 Apr 2019 at 07:59, Jochen Wiedmann <jo...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org