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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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.

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