Inheritance behaviour for MNG-5951 attributes?

[Mark Raynsford]

Let's say I have the following:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>a</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<scm child.inherit.append.path="false">
<url>https://example.com/a</url>
<connection>scm:git:https://example.com/a</connection>
<developerConnection>scm:git:https://example.com/a</developerConnection>
</scm>
</project>

And then:

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.example</groupId>
<artifactId>a</artifactId>
<version>1.0.0</version>
</parent>
<groupId>com.example</groupId>
<artifactId>b</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<scm>
<url>https://example.com/b</url>
<connection>scm:git:https://example.com/b</connection>
<developerConnection>scm:git:https://example.com/b</developerConnection>
</scm>
</project>

And then:

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.example</groupId>
<artifactId>b</artifactId>
<version>1.0.0</version>
</parent>
<groupId>com.example</groupId>
<artifactId>c</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
</project>

So that's com.example:a:1.0.0 → com.example:b:1.0.0 →
com.example:c:1.0.0.

Would you expect com.example:c:1.0.0 to have
child.inherit.append.path="true" for the (inherited) <scm> element? It
wasn't clear exactly what semantics were intended to be. What I *think*
is happening right now is that the <scm> element in com.example:b:1.0.0
is assigned a value of child.inherit.append.path="true", because "true"
is the default if something isn't specified and it overrides the value
specified in com.example:a:1.0.0.

[Hervé BOUTEMY]

Hi Mark,

Seems you found one more thing that I forgot when merging MNG-6059:
inheritance of these child.inherit.append.path configurations...

I created MNG-6505 [1] and added the fix to MNG-6059 branch.

Can you check that it works as you expect? (notice: with the new
child.x.y.inherit.append.path names...)


Thank you for the tests and reports: this really helps a lot to improve
quality.

Regards,

Hervé

[1] https://issues.apache.org/jira/browse/MNG-6505

Post by Mark Raynsford
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>a</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<scm child.inherit.append.path="false">
<url>https://example.com/a</url>
<connection>scm:git:https://example.com/a</connection>
<developerConnection>scm:git:https://example.com/a</developerConnection>
</scm>
</project>
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.example</groupId>
<artifactId>a</artifactId>
<version>1.0.0</version>
</parent>
<groupId>com.example</groupId>
<artifactId>b</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<scm>
<url>https://example.com/b</url>
<connection>scm:git:https://example.com/b</connection>
<developerConnection>scm:git:https://example.com/b</developerConnection>
</scm>
</project>
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.example</groupId>
<artifactId>b</artifactId>
<version>1.0.0</version>
</parent>
<groupId>com.example</groupId>
<artifactId>c</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
</project>
So that's com.example:a:1.0.0 → com.example:b:1.0.0 →
com.example:c:1.0.0.
Would you expect com.example:c:1.0.0 to have
child.inherit.append.path="true" for the (inherited) <scm> element? It
wasn't clear exactly what semantics were intended to be. What I *think*
is happening right now is that the <scm> element in com.example:b:1.0.0
is assigned a value of child.inherit.append.path="true", because "true"
is the default if something isn't specified and it overrides the value
specified in com.example:a:1.0.0.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@maven.apache.org
For additional commands, e-mail: dev-***@maven.apache.org

[Mark Raynsford]

On 2018-11-04T13:34:39 +0100

Post by Hervé BOUTEMY
Hi Mark,
inheritance of these child.inherit.append.path configurations...
I created MNG-6505 [1] and added the fix to MNG-6059 branch.
Can you check that it works as you expect? (notice: with the new
child.x.y.inherit.append.path names...)

Can do! Which code should I be building? Not sure if this work is
happening on a branch somewhere.

Post by Hervé BOUTEMY
Thank you for the tests and reports: this really helps a lot to improve
quality.

You're welcome!

[Hervé BOUTEMY]

you can build https://github.com/apache/maven/tree/MNG-6059 with quick build
instruction at the end of README

Regards,

Hervé

Post by Mark Raynsford
On 2018-11-04T13:34:39 +0100

Post by Hervé BOUTEMY
Hi Mark,
inheritance of these child.inherit.append.path configurations...
I created MNG-6505 [1] and added the fix to MNG-6059 branch.
Can you check that it works as you expect? (notice: with the new
child.x.y.inherit.append.path names...)

Can do! Which code should I be building? Not sure if this work is
happening on a branch somewhere.

Post by Hervé BOUTEMY
Thank you for the tests and reports: this really helps a lot to improve
quality.

You're welcome!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@maven.apache.org
For additional commands, e-mail: dev-***@maven.apache.org

[Mark Raynsford]

On 2018-11-04T15:34:11 +0100

Post by Hervé BOUTEMY
you can build https://github.com/apache/maven/tree/MNG-6059 with quick build
instruction at the end of README

Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
seems to be working for all but the
project/distributionManagement/site/@child.site.url.inherit.append.path
element. I have this in my organization-wide POM:

https://github.com/io7m/primogenitor/blob/release/3.0.0-beta0019/pom.xml#L126

I then use the property in BND bundle manifests:

https://github.com/io7m/primogenitor/blob/release/3.0.0-beta0019/pom.xml#L433

The $[...] syntax is just BND-speak for "expand this property as late
as possible". Using the traditional ${...} syntax can cause those
properties to be expanded too early, resulting in the values as they
appeared in the parent being used in child modules.

Then, in a descendant project:

https://github.com/io7m/junreachable/blob/release/3.0.0/pom.xml#L39
https://github.com/io7m/junreachable/blob/release/3.0.0/pom.xml#L60

If I look at the resulting OSGi manifest for the
com.io7m.junreachable.core module, I see:

Bundle-Description Exception types for marking unreachable/unimplemented code (Core)
Bundle-DocURL https://www.io7m.com/software/junreachable/com.io7m.junreachable.core
Bundle-ManifestVersion 2
Bundle-Name com.io7m.junreachable.core 3.0.0 - Exception types for marking unreachable/unimplemented code (Core)
Bundle-SCM https://github.com/io7m/junreachable
Bundle-SymbolicName com.io7m.junreachable.core
Bundle-Vendor io7m.com
Bundle-Version 3.0.0
Export-Package com.io7m.junreachable;version="3.0.0"
Implementation-Build e519345f73b1d2f4c9393eadbf9909ac361a0751
Implementation-Title com.io7m.junreachable.core
Implementation-Vendor io7m.com
Implementation-Vendor-Id com.io7m.junreachable
Implementation-Version 3.0.0
Manifest-Version 1.0
Require-Capability osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"
Sealed true
Specification-Title com.io7m.junreachable.core
Specification-Vendor io7m.com
Specification-Version 3.0.0

So you can see that the Bundle-SCM field, which is built from
${project.scm.url}, has the correct non-appended value. However,
Bundle-DocURL, which is built from
${project.distributionManagement.site.url}, still has the module
name appended to it.

[Mark Raynsford]

On 2018-11-04T15:05:19 +0000

Post by Mark Raynsford
On 2018-11-04T15:34:11 +0100

Post by Hervé BOUTEMY
you can build https://github.com/apache/maven/tree/MNG-6059 with quick build
instruction at the end of README

Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
seems to be working for all but the
element.

Here's a more isolated example:

https://github.com/io7m/mng-6059-examples/tree/develop/abc

Note that the jar in the 'c' module has the following fields:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.1-SNAPSHOT
Built-By: rm
Build-Jdk: 11
Field-SCM: https://github.com/io7m/mng-6059-examples
Field-Site: https://www.io7m.com/software/mng-6059-examples/com.io7m.c
Field-URL: http://www.io7m.com/

The Field-SCM and Field-URL attributes have the automatic appending
correctly disabled, but the Field-Site attribute still has the module
appended despite the fact that the site element in
distributionManagement has child.site.url.inherit.append.path="false".

[Hervé BOUTEMY]

Hi Mark,

even if this is somewhat a corner case (while overriding everything in b, you
can override the attribute also), it is strange...

The more immediate check is to run "mvn help:effective-pom" on b to check that
child.site.url.inherit.append.path is configured: I still don't understand
why, but it is not.

I can reproduce the issue in an inheritance unit test (no-append-urls in
maven-model-builder), but still need to investigate why it does not work as
intended by ModelMerger.mergeSite(...): you can easily check by removing
"name" field in b, you'll see that merge for other fields does not work

I'll investigate later, it's late here now :)

Regards,

Hervé

Post by Mark Raynsford
On 2018-11-04T15:05:19 +0000

Post by Mark Raynsford
On 2018-11-04T15:34:11 +0100

Post by Hervé BOUTEMY
you can build https://github.com/apache/maven/tree/MNG-6059 with quick
build instruction at the end of README

Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
seems to be working for all but the
element.

https://github.com/io7m/mng-6059-examples/tree/develop/abc
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.1-SNAPSHOT
Built-By: rm
Build-Jdk: 11
Field-SCM: https://github.com/io7m/mng-6059-examples
Field-Site: https://www.io7m.com/software/mng-6059-examples/com.io7m.c
Field-URL: http://www.io7m.com/
The Field-SCM and Field-URL attributes have the automatic appending
correctly disabled, but the Field-Site attribute still has the module
appended despite the fact that the site element in
distributionManagement has child.site.url.inherit.append.path="false".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@maven.apache.org
For additional commands, e-mail: dev-***@maven.apache.org

[Mark Raynsford]

'Ello.

On 2018-11-06T00:03:53 +0100

Post by Hervé BOUTEMY
Hi Mark,
even if this is somewhat a corner case (while overriding everything in b, you
can override the attribute also), it is strange...

I'm not sure it's a corner case, exactly. It reflects the real-life
situation I'm in: Consider a tree where 'a' is the root, and there are
a large number of projects (at the depth of 'b') that all inherit from
'a'. In my case "large" means "more than seventy" so, as you can
imagine, I'm not enthusiastic about going through all of those projects
and adding an attribute just to to fix a bug in Maven. :) In my case,
there are over 400 modules at the depth of 'c' spread across all of the
'b'-level projects.

Post by Hervé BOUTEMY
I can reproduce the issue in an inheritance unit test (no-append-urls in
maven-model-builder), but still need to investigate why it does not work as
intended by ModelMerger.mergeSite(...): you can easily check by removing
"name" field in b, you'll see that merge for other fields does not work

Good to know it's reproducible in tests.

[Hervé BOUTEMY]

Post by Mark Raynsford
'Ello.
On 2018-11-06T00:03:53 +0100

Post by Hervé BOUTEMY
Hi Mark,
even if this is somewhat a corner case (while overriding everything in b,
you can override the attribute also), it is strange...

I'm not sure it's a corner case, exactly. It reflects the real-life
situation I'm in: Consider a tree where 'a' is the root, and there are
a large number of projects (at the depth of 'b') that all inherit from
'a'. In my case "large" means "more than seventy" so, as you can
imagine, I'm not enthusiastic about going through all of those projects
and adding an attribute just to to fix a bug in Maven. :) In my case,
there are over 400 modules at the depth of 'c' spread across all of the
'b'-level projects.

Post by Hervé BOUTEMY
I can reproduce the issue in an inheritance unit test (no-append-urls in
maven-model-builder), but still need to investigate why it does not work as
intended by ModelMerger.mergeSite(...): you can easily check by removing
"name" field in b, you'll see that merge for other fields does not work

Good to know it's reproducible in tests.

in fact, you can also reproduce by defining in b:
<distributionManagement>
<site>
<name>name from B</name>
</site>
</distributionManagement>

If you look at effective pom, you'll see that id and url are unexpectedly not inherited...

You discovered an edge case with the new attribute that already exists with elements: I still didn't have time yet to investigate on the cause, but will do

Regards,

Hervé




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@maven.apache.org
For additional commands, e-mail: dev-***@maven.apache.org

[Hervé BOUTEMY]

ok, I investigated more in details and added a little trick in [1]:
child.site.url.inherit.append.path is inherited independantly from id/name/url

this will manage your edge case, which I can understand is expected

do you think it is ok?

Regards,

Hervé

[1] https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=11312d5b275260fbd2b3ed3294da3ccff5413d42

Post by Mark Raynsford
'Ello.
On 2018-11-06T00:03:53 +0100

Post by Hervé BOUTEMY
Hi Mark,
even if this is somewhat a corner case (while overriding everything in b,
you can override the attribute also), it is strange...

I'm not sure it's a corner case, exactly. It reflects the real-life
situation I'm in: Consider a tree where 'a' is the root, and there are
a large number of projects (at the depth of 'b') that all inherit from
'a'. In my case "large" means "more than seventy" so, as you can
imagine, I'm not enthusiastic about going through all of those projects
and adding an attribute just to to fix a bug in Maven. :) In my case,
there are over 400 modules at the depth of 'c' spread across all of the
'b'-level projects.

it's a corner case just because in b, you define
distributionManagement.site.id, name and url, but not
@child.site.url.inherit.append.path: just define this attribute while at it
(instead of counting on inheritance) and it will work as expected. Like
proposed in https://github.com/io7m/mng-6059-examples/pull/1

Post by Mark Raynsford

Post by Hervé BOUTEMY
I can reproduce the issue in an inheritance unit test (no-append-urls in
maven-model-builder), but still need to investigate why it does not work as
intended by ModelMerger.mergeSite(...): you can easily check by removing
"name" field in b, you'll see that merge for other fields does not work

Good to know it's reproducible in tests.

<distributionManagement>
<site>
<name>name from B</name>
</site>
</distributionManagement>
If you look at effective pom, you'll see that id and url are unexpectedly not inherited...
You discovered an edge case with the new attribute that already exists with
elements: I still didn't have time yet to investigate on the cause, but
will do
Regards,
Hervé
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@maven.apache.org
For additional commands, e-mail: dev-***@maven.apache.org

[Mark Raynsford]

On 2018-11-10T16:47:59 +0100

Post by Hervé BOUTEMY
child.site.url.inherit.append.path is inherited independantly from id/name/url
this will manage your edge case, which I can understand is expected
do you think it is ok?

I'll build and test this shortly! Thanks.

[Mark Raynsford]

Post by Mark Raynsford
On 2018-11-10T16:47:59 +0100

Post by Hervé BOUTEMY
child.site.url.inherit.append.path is inherited independantly from id/name/url
this will manage your edge case, which I can understand is expected
do you think it is ok?

11312d5b275260fbd2b3ed3294da3ccff5413d42 gives me the results I'd
expect:

$ unzip -p b/c/target/com.io7m.c-1.0.0.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven 3.6.1-SNAPSHOT
Built-By: rm
Build-Jdk: 11
Field-SCM: https://github.com/io7m/mng-6059-examples
Field-Site: https://www.io7m.com/software/mng-6059-examples
Field-URL: http://www.io7m.com/

Nice work!