You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Raynsford <or...@io7m.com.INVALID> on 2018/11/03 18:11:26 UTC
Inheritance behaviour for MNG-5951 attributes?
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.
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
> On 2018-11-10T16:47:59 +0100
> Hervé BOUTEMY <he...@free.fr> wrote:
>
> > 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?
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!
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
On 2018-11-10T16:47:59 +0100
Hervé BOUTEMY <he...@free.fr> wrote:
> 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?
I'll build and test this shortly! Thanks.
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Hervé BOUTEMY <he...@free.fr>.
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
Le mercredi 7 novembre 2018, 00:03:19 CET Hervé BOUTEMY a écrit :
> Le mardi 6 novembre 2018, 10:35:25 CET Mark Raynsford a écrit :
> > 'Ello.
> >
> > On 2018-11-06T00:03:53 +0100
> >
> > Hervé BOUTEMY <he...@free.fr> wrote:
> > > 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
> > > 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 6 novembre 2018, 10:35:25 CET Mark Raynsford a écrit :
> 'Ello.
>
> On 2018-11-06T00:03:53 +0100
>
> Hervé BOUTEMY <he...@free.fr> wrote:
> > 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
>
> > 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
'Ello.
On 2018-11-06T00:03:53 +0100
Hervé BOUTEMY <he...@free.fr> wrote:
> 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.
> 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.
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Hervé BOUTEMY <he...@free.fr>.
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é
Le lundi 5 novembre 2018, 13:19:43 CET Mark Raynsford a écrit :
> On 2018-11-04T15:05:19 +0000
>
> Mark Raynsford <or...@io7m.com> wrote:
> > On 2018-11-04T15:34:11 +0100
> >
> > Hervé BOUTEMY <he...@free.fr> wrote:
> > > 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.
>
> 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".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
On 2018-11-04T15:05:19 +0000
Mark Raynsford <or...@io7m.com> wrote:
> On 2018-11-04T15:34:11 +0100
> Hervé BOUTEMY <he...@free.fr> wrote:
>
> > 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.
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".
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
On 2018-11-04T15:34:11 +0100
Hervé BOUTEMY <he...@free.fr> wrote:
> 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 | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Hervé BOUTEMY <he...@free.fr>.
you can build https://github.com/apache/maven/tree/MNG-6059 with quick build
instruction at the end of README
Regards,
Hervé
Le dimanche 4 novembre 2018, 13:48:51 CET Mark Raynsford a écrit :
> On 2018-11-04T13:34:39 +0100
>
> Hervé BOUTEMY <he...@free.fr> wrote:
> > 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...)
>
> Can do! Which code should I be building? Not sure if this work is
> happening on a branch somewhere.
>
> > Thank you for the tests and reports: this really helps a lot to improve
> > quality.
>
> You're welcome!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Mark Raynsford <or...@io7m.com.INVALID>.
On 2018-11-04T13:34:39 +0100
Hervé BOUTEMY <he...@free.fr> wrote:
> 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...)
Can do! Which code should I be building? Not sure if this work is
happening on a branch somewhere.
> Thank you for the tests and reports: this really helps a lot to improve
> quality.
You're welcome!
--
Mark Raynsford | http://www.io7m.com
Re: Inheritance behaviour for MNG-5951 attributes?
Posted by Hervé BOUTEMY <he...@free.fr>.
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
Le samedi 3 novembre 2018, 19:11:26 CET Mark Raynsford a écrit :
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org