[jira] [Commented] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826394#comment-16826394
]
Robert Thornton commented on MNG-6644:
--
I tested against branch [https://github.com/apache/maven/tree/MNG-6636] and it
fixes the issue.
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
>
[jira] [Comment Edited] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826359#comment-16826359
]
Robert Thornton edited comment on MNG-6644 at 4/25/19 6:52 PM:
---
Although the fix for this issue might be the same as for MNG-6636, I don't
believe this issue is necessarily a duplicate because the Maven model, in my
case, is not being parsed from xml. Rather it is being created programmatically
using the polykot-maven extension for kotlin, so InputLocation will always be
null regardless of whether the list of reports is empty or not. For this
reason, the workaround does not work for me, so I have to stay on Maven 3.6.0.
But as long as the fix for MNG-6636 performs a null check of InputLocation, it
should solve this issue.
was (Author: rptmaestro):
Although the fix for this issue might be the same as for MNG-6636, I don't
believe this issue is necessarily a duplicate because the Maven model, in my
case, is not being parsed from xml. Rather it is being created programmatically
using the maven-polykot extension, so InputLocation will always be null
regardless of whether the list of reports is empty or not. For this reason, the
workaround does not work for me, so I have to stay on Maven 3.6.0. But as long
as the fix for MNG-6636 performs a null check of InputLocation, it should solve
this issue.
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at
[jira] [Commented] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16826359#comment-16826359
]
Robert Thornton commented on MNG-6644:
--
Although the fix for this issue might be the same as for MNG-6636, I don't
believe this issue is necessarily a duplicate because the Maven model, in my
case, is not being parsed from xml. Rather it is being created programmatically
using the maven-polykot extension, so InputLocation will always be null
regardless of whether the list of reports is empty or not. For this reason, the
workaround does not work for me, so I have to stay on Maven 3.6.0. But as long
as the fix for MNG-6636 performs a null check of InputLocation, it should solve
this issue.
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at
[jira] [Commented] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
[
https://issues.apache.org/jira/browse/MNG-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819374#comment-16819374
]
Robert Thornton commented on MNG-6644:
--
The exception is getting thrown in DefaultReportingConverter, line 243, most
likely because the `location` variable is null when the pom is generated by a
script rather than loaded from XML.
> NPE in DefaultReportingConverter when reports has no InputLocation
> --
>
> Key: MNG-6644
> URL: https://issues.apache.org/jira/browse/MNG-6644
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-3.6.1-reporting-bug.zip
>
>
> After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
> with a NullPointerException. This project uses the extension
> `io.takari.polyglot:polyglot-kotlin` in order to build the Maven project
> model using a Kotlin script.
> {code:java}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
> Caused by: java.lang.NullPointerException
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:243)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convert
> (DefaultReportingConverter.java:213)
> at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
> (DefaultReportingConverter.java:140)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:479)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:432)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:616)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:385)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> at
[jira] [Created] (MNG-6644) NPE in DefaultReportingConverter when reports has no InputLocation
Robert Thornton created MNG-6644:
Summary: NPE in DefaultReportingConverter when reports has no
InputLocation
Key: MNG-6644
URL: https://issues.apache.org/jira/browse/MNG-6644
Project: Maven
Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Robert Thornton
Attachments: maven-3.6.1-reporting-bug.zip
After upgrading from Maven 3.6.0 to Maven 3.6.1, the attached project fails
with a NullPointerException. This project uses the extension
`io.takari.polyglot:polyglot-kotlin` in order to build the Maven project model
using a Kotlin script.
{code:java}
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:39)
at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
Caused by: java.lang.NullPointerException
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:243)
at org.apache.maven.model.plugin.DefaultReportingConverter.convert
(DefaultReportingConverter.java:213)
at org.apache.maven.model.plugin.DefaultReportingConverter.convertReporting
(DefaultReportingConverter.java:140)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:479)
at org.apache.maven.model.building.DefaultModelBuilder.build
(DefaultModelBuilder.java:432)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:616)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:385)
at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
(DefaultGraphBuilder.java:414)
at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
(DefaultGraphBuilder.java:405)
at org.apache.maven.graph.DefaultGraphBuilder.build
(DefaultGraphBuilder.java:82)
at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:39)
at org.apache.maven.wrapper.WrapperExecutor.execute (WrapperExecutor.java:122)
at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:55)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762460#comment-16762460
]
Robert Thornton commented on MNG-6585:
--
In the attached sample project, the extensions.xml file references a snapshot
version. Running the maven build fails because it isn't even trying to download
version 0.3.3-SNAPSHOT. If I change the version to 0.3.3, then the maven build
does attempt to download the artifact.
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-extensions-bug.zip
>
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with a warning
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or not because my plugin repository in
> settings.xml has been configured to allow snapshots.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6585:
-
Attachment: maven-extensions-bug.zip
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
> Attachments: maven-extensions-bug.zip
>
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with a warning
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or not because my plugin repository in
> settings.xml has been configured to allow snapshots.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6585:
-
Description:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with a warning that it could not find the
extension without explaining why it didn't try to download it. This means that
in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or not because my plugin repository in settings.xml
has been configured to allow snapshots.
was:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with a warning that it could not find the
extension without explaining why it didn't try to download it. This means that
in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or not.
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with a warning
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or not because my plugin repository in
> settings.xml has been configured to allow snapshots.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6585:
-
Description:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with a warning that it could not find the
extension without explaining why it didn't try to download it. This means that
in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or not.
was:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with a warning that it could not find the
extension without explaining why it didn't try to download it. This means that
in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with a warning
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6585:
-
Description:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with a warning that it could not find the
extension without explaining why it didn't try to download it. This means that
in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
was:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with the message that it could not find
the extension without explaining why it didn't try to download it. This means
that in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with a warning
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6585) Unable to load snapshot extensions from extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6585:
-
Description:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with the message that it could not find
the extension without explaining why it didn't try to download it. This means
that in order for me to try out the extension, I have either have to build it
locally or make a release first. I've been unable to find any documentation
that identifies this as an intentional limitation, which leads me to believe it
must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
was:
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with the message that it could not find
the extension without explaining why it didn't try to download it. This means
that in order for other builds to try out the extension, I have to make a
release first. I've been unable to find any documentation that identifies this
as an intentional limitation, which leads me to believe it must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
> Unable to load snapshot extensions from extensions.xml
> --
>
> Key: MNG-6585
> URL: https://issues.apache.org/jira/browse/MNG-6585
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9, 3.5.4, 3.6.0
>Reporter: Robert Thornton
>Priority: Major
>
> I'm developing an extension in a continuous build environment and Maven
> doesn't even attempt to download the extension if the entry in
> .mvn/extensions.xml has a -SNAPSHOT version. It simply fails with the message
> that it could not find the extension without explaining why it didn't try to
> download it. This means that in order for me to try out the extension, I have
> either have to build it locally or make a release first. I've been unable to
> find any documentation that identifies this as an intentional limitation,
> which leads me to believe it must be a bug.
> For example, my extension allows the pom.xml to be written in a Kotlin DSL.
> Because my pom is named pom.kts instead of pom.xml, my build will fail if it
> cannot download the extension as defined below:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3-SNAPSHOT
>
>
> {code}
> However, if I change the version to a non-snapshot, Maven does attempt to
> download the extension:
> {code:java}
>
>
>
> io.takari.polyglot
> polyglot-kotlin
> 0.3.3.beta01
>
> {code}
> It seems to me that Maven should attempt to resolve the extension regardless
> of whether it is a snapshot or now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6585) Unable to load snapshot extensions from extensions.xml
Robert Thornton created MNG-6585:
Summary: Unable to load snapshot extensions from extensions.xml
Key: MNG-6585
URL: https://issues.apache.org/jira/browse/MNG-6585
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.6.0, 3.5.4, 3.3.9
Reporter: Robert Thornton
I'm developing an extension in a continuous build environment and Maven doesn't
even attempt to download the extension if the entry in .mvn/extensions.xml has
a -SNAPSHOT version. It simply fails with the message that it could not find
the extension without explaining why it didn't try to download it. This means
that in order for other builds to try out the extension, I have to make a
release first. I've been unable to find any documentation that identifies this
as an intentional limitation, which leads me to believe it must be a bug.
For example, my extension allows the pom.xml to be written in a Kotlin DSL.
Because my pom is named pom.kts instead of pom.xml, my build will fail if it
cannot download the extension as defined below:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3-SNAPSHOT
{code}
However, if I change the version to a non-snapshot, Maven does attempt to
download the extension:
{code:java}
io.takari.polyglot
polyglot-kotlin
0.3.3.beta01
{code}
It seems to me that Maven should attempt to resolve the extension regardless of
whether it is a snapshot or now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
[
https://issues.apache.org/jira/browse/MNG-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676157#comment-16676157
]
Robert Thornton commented on MNG-6455:
--
Note that this issue does not happen when the parent is discoverable via
, only when the parent has to be looked up from the repository.
For this reason, I set an empty to force parent lookup from the
repository.
My use case is that my parent pom is reused by many projects in my
organization, each having their own source code repository. Because my pom has
to be looked up, that is why my users are seeing the "Failed to build parent
project" error every time they build, and I have to continually reassure them
that there is nothing wrong with their build.
> ci-friendly version in parent pom displays build warning in child project
> -
>
> Key: MNG-6455
> URL: https://issues.apache.org/jira/browse/MNG-6455
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Thornton
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: mng-6455.zip
>
>
> I have a project that is using a parent project with ci-friendly versions,
> but while Maven is scanning for projects, it is looking for
> "my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The
> project builds, but a warning is printed which confuses some of the teams
> using my parent pom.
> {{[INFO] Scanning for projects...}}
> {{Downloading from mvn-lds:
> https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
> {{[WARNING] Failed to build parent project for
> my.stack.platform:my-project:pom:4.8.2.RELEASE}}
>
> I've tracked the issue down to DefaultProjectBuilder, line 671 where
> `project.getParentArtifact()` is returning an Artifact object with the
> unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
[
https://issues.apache.org/jira/browse/MNG-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676149#comment-16676149
]
Robert Thornton commented on MNG-6455:
--
I've attached the steps to reproduce. Please verify and reopen this issue.
> ci-friendly version in parent pom displays build warning in child project
> -
>
> Key: MNG-6455
> URL: https://issues.apache.org/jira/browse/MNG-6455
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Thornton
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: mng-6455.zip
>
>
> I have a project that is using a parent project with ci-friendly versions,
> but while Maven is scanning for projects, it is looking for
> "my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The
> project builds, but a warning is printed which confuses some of the teams
> using my parent pom.
> {{[INFO] Scanning for projects...}}
> {{Downloading from mvn-lds:
> https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
> {{[WARNING] Failed to build parent project for
> my.stack.platform:my-project:pom:4.8.2.RELEASE}}
>
> I've tracked the issue down to DefaultProjectBuilder, line 671 where
> `project.getParentArtifact()` is returning an Artifact object with the
> unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
[
https://issues.apache.org/jira/browse/MNG-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676146#comment-16676146
]
Robert Thornton commented on MNG-6455:
--
[^mng-6455.zip]
^Steps to reproduce:^
# Unzip the attached file
# Run {{*mvn -f parent-pom.xml install*}}
# Run {{*mvn -f child-pom.xml install*}}
# The output will begin with the following:
{{[INFO] Scanning for projects...}}
{{Downloading from central:
[https://repo.maven.apache.org/maven2/com/example/parent-pom/$%7Brevision%7D/parent-pom-$%7Brevision%7D.pom]}}
{{[WARNING] Failed to build parent project for
com.example:child-bom:pom:1.0.0-SNAPSHOT}}
> ci-friendly version in parent pom displays build warning in child project
> -
>
> Key: MNG-6455
> URL: https://issues.apache.org/jira/browse/MNG-6455
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Thornton
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: mng-6455.zip
>
>
> I have a project that is using a parent project with ci-friendly versions,
> but while Maven is scanning for projects, it is looking for
> "my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The
> project builds, but a warning is printed which confuses some of the teams
> using my parent pom.
> {{[INFO] Scanning for projects...}}
> {{Downloading from mvn-lds:
> https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
> {{[WARNING] Failed to build parent project for
> my.stack.platform:my-project:pom:4.8.2.RELEASE}}
>
> I've tracked the issue down to DefaultProjectBuilder, line 671 where
> `project.getParentArtifact()` is returning an Artifact object with the
> unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
[
https://issues.apache.org/jira/browse/MNG-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-6455:
-
Attachment: mng-6455.zip
> ci-friendly version in parent pom displays build warning in child project
> -
>
> Key: MNG-6455
> URL: https://issues.apache.org/jira/browse/MNG-6455
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Thornton
>Priority: Minor
> Fix For: waiting-for-feedback
>
> Attachments: mng-6455.zip
>
>
> I have a project that is using a parent project with ci-friendly versions,
> but while Maven is scanning for projects, it is looking for
> "my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The
> project builds, but a warning is printed which confuses some of the teams
> using my parent pom.
> {{[INFO] Scanning for projects...}}
> {{Downloading from mvn-lds:
> https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
> {{[WARNING] Failed to build parent project for
> my.stack.platform:my-project:pom:4.8.2.RELEASE}}
>
> I've tracked the issue down to DefaultProjectBuilder, line 671 where
> `project.getParentArtifact()` is returning an Artifact object with the
> unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
Robert Thornton created MNG-6455:
Summary: ci-friendly version in parent pom displays build warning
in child project
Key: MNG-6455
URL: https://issues.apache.org/jira/browse/MNG-6455
Project: Maven
Issue Type: Bug
Reporter: Robert Thornton
I have a project that is using a parent project with ci-friendly versions, but
while Maven is scanning for projects, it is looking for
"my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The project
builds, but a warning is printed which confuses some of the teams using my
parent pom.
{{[INFO] Scanning for projects...}}
{{Downloading from mvn-lds:
https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
{{[WARNING] Failed to build parent project for
my.stack.platform:my-project:pom:4.8.2.RELEASE}}
I've tracked the issue down to DefaultProjectBuilder, line 671 where
`project.getParentArtifact()` is returning an Artifact object with the
unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-935) Support for expression in 'version' tag
[
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359091#comment-16359091
]
Robert Thornton edited comment on MRELEASE-935 at 2/9/18 11:27 PM:
---
I would also like the release plugin to support this feature. For example,
maven does support the ${revision} expression in the version tag in which case
the property is expected not to have any expressions inside it.
See: https://maven.apache.org/maven-ci-friendly.html
However, the ${revision} expression is lost when the release plugin sets the
development version.
I've attached a patch that resolves this issue.
[^support_for_revision_in_version.patch]
was (Author: rptmaestro):
I would also like the release plugin to support this feature. For example,
maven does support the ${revision} expression in the version tag in which case
the property is expected not to have any expressions inside it.
However, the ${revision} expression is lost when the release plugin sets the
development version.
I've attached a patch that resolves this issue.
[^support_for_revision_in_version.patch]
> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-935) Support for expression in 'version' tag
[
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359091#comment-16359091
]
Robert Thornton commented on MRELEASE-935:
--
I would also like the release plugin to support this feature. For example,
maven does support the ${revision} expression in the version tag in which case
the property is expected not to have any expressions inside it.
However, the ${revision} expression is lost when the release plugin sets the
development version.
I've attached a patch that resolves this issue.
[^support_for_revision_in_version.patch]
> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-935) Support for expression in 'version' tag
[
https://issues.apache.org/jira/browse/MRELEASE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MRELEASE-935:
-
Attachment: support_for_revision_in_version.patch
> Support for expression in 'version' tag
> ---
>
> Key: MRELEASE-935
> URL: https://issues.apache.org/jira/browse/MRELEASE-935
> Project: Maven Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.5.3
>Reporter: Andrea Scarpino
>Priority: Critical
> Attachments: support_for_revision_in_version.patch
>
>
> The release plugin doesn't support a version value that points to a property
> which define the version.
> Everytime I use the plugin, the version in the current POM loose the
> expression. Maybe it could work using the property to which it points?
> {noformat}
> $ grep '' pom.xml
> ${parent.project.version}
> $ grep '' pom.xml
> 0.0.1-SNAPSHOT
> {noformat}
> Could you please implement this or point me to the files that handle this?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-4463) Dependency management import should support version ranges.
[
https://issues.apache.org/jira/browse/MNG-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347255#comment-16347255
]
Robert Thornton edited comment on MNG-4463 at 1/31/18 5:43 PM:
---
Does this fix also allow expressions in the version? For example:
{code:xml}
group
artifact
${artifact.version}
pom
import
{code}
was (Author: rptmaestro):
Does this fix also allow expressions in the version? For example:
groupartifact${artifact.version}pomimport
> Dependency management import should support version ranges.
> ---
>
> Key: MNG-4463
> URL: https://issues.apache.org/jira/browse/MNG-4463
> Project: Maven
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 2.2.1
>Reporter: Rob ten Hove
>Priority: Major
> Fix For: 3.5.x-candidate
>
>
> Version ranges cannot be used for artifacts with {{import}} scope. If a
> version range is used for such an artifact, Maven cannot find it. Looking at
> the console output shows that it takes the version range as the version,
> without resolving it:
> {noformat}Downloading:
> http://some-repo/group/artifact/[1.0.0,2.0.0)/artifact-[1.0.0,2.0.0).pom{noformat}
> This is the POM snippet:
> {code:xml}
>
>
>
> group
> artifact
> [1.0.0,2.0.0)
>
> pom
> import
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-4463) Dependency management import should support version ranges.
[
https://issues.apache.org/jira/browse/MNG-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347255#comment-16347255
]
Robert Thornton commented on MNG-4463:
--
Does this fix also allow expressions in the version? For example:
groupartifact${artifact.version}pomimport
> Dependency management import should support version ranges.
> ---
>
> Key: MNG-4463
> URL: https://issues.apache.org/jira/browse/MNG-4463
> Project: Maven
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 2.2.1
>Reporter: Rob ten Hove
>Priority: Major
> Fix For: 3.5.x-candidate
>
>
> Version ranges cannot be used for artifacts with {{import}} scope. If a
> version range is used for such an artifact, Maven cannot find it. Looking at
> the console output shows that it takes the version range as the version,
> without resolving it:
> {noformat}Downloading:
> http://some-repo/group/artifact/[1.0.0,2.0.0)/artifact-[1.0.0,2.0.0).pom{noformat}
> This is the POM snippet:
> {code:xml}
>
>
>
> group
> artifact
> [1.0.0,2.0.0)
>
> pom
> import
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SUREFIRE-1191) Run Single Test with Package Name Doesn't work
[
https://issues.apache.org/jira/browse/SUREFIRE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988568#comment-14988568
]
Robert Thornton edited comment on SUREFIRE-1191 at 11/4/15 1:21 AM:
[~tibor17]
This issue is most definitely a bug--not a request for a new feature. Support
for this feature has been around for a long time.
The following command works for every version of surefire from 2.4 to 2.18:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test
-Dtest=mypackage.MyTest
{code}
It only stopped working with surefire:2.19:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test
-Dtest=mypackage.MyTest
{code}
was (Author: rptmaestro):
Tibor Digana
This issue is most definitely a bug--not a request for a new feature. Support
for this feature has been around for a long time.
The following command works for every version of surefire from 2.4 to 2.18:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test
-Dtest=mypackage.MyTest
{code}
It only stopped working with surefire:2.19:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test
-Dtest=mypackage.MyTest
{code}
> Run Single Test with Package Name Doesn't work
> --
>
> Key: SUREFIRE-1191
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1191
> Project: Maven Surefire
> Issue Type: Wish
>Affects Versions: 2.19
>Reporter: Gunnar Schmidt
>Assignee: Tibor Digana
> Fix For: 3.0
>
>
> Running the following command works:
> mvn test -Dtest=MyTestCaseTest#myTest
> This doesn't work (package name included):
> mvn test -Dtest=my.package.name.MyTestCaseTest#myTest
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1191) Run Single Test with Package Name Doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988568#comment-14988568 ] Robert Thornton commented on SUREFIRE-1191: --- Tibor Digana This issue is most definitely a bug. The following command works for every version of surefire from 2.4 to 2.18: mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test -Dtest=mypackage.MyTest It only stopped working with surefire:2.19: mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test -Dtest=mypackage.MyTest > Run Single Test with Package Name Doesn't work > -- > > Key: SUREFIRE-1191 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1191 > Project: Maven Surefire > Issue Type: Wish >Affects Versions: 2.19 >Reporter: Gunnar Schmidt >Assignee: Tibor Digana > Fix For: 3.0 > > > Running the following command works: > mvn test -Dtest=MyTestCaseTest#myTest > This doesn't work (package name included): > mvn test -Dtest=my.package.name.MyTestCaseTest#myTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1191) Run Single Test with Package Name Doesn't work
[
https://issues.apache.org/jira/browse/SUREFIRE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988568#comment-14988568
]
Robert Thornton edited comment on SUREFIRE-1191 at 11/4/15 1:16 AM:
Tibor Digana
This issue is most definitely a bug--not a request for a new feature. Support
for this feature has been around for a long time.
The following command works for every version of surefire from 2.4 to 2.18:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test
-Dtest=mypackage.MyTest
{code}
It only stopped working with surefire:2.19:
{code}
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test
-Dtest=mypackage.MyTest
{code}
was (Author: rptmaestro):
Tibor Digana
This issue is most definitely a bug--not a request for a new feature. Support
for this feature has been around for a long time.
The following command works for every version of surefire from 2.4 to 2.18:
mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test
-Dtest=mypackage.MyTest
It only stopped working with surefire:2.19:
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test
-Dtest=mypackage.MyTest
> Run Single Test with Package Name Doesn't work
> --
>
> Key: SUREFIRE-1191
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1191
> Project: Maven Surefire
> Issue Type: Wish
>Affects Versions: 2.19
>Reporter: Gunnar Schmidt
>Assignee: Tibor Digana
> Fix For: 3.0
>
>
> Running the following command works:
> mvn test -Dtest=MyTestCaseTest#myTest
> This doesn't work (package name included):
> mvn test -Dtest=my.package.name.MyTestCaseTest#myTest
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-1191) Run Single Test with Package Name Doesn't work
[ https://issues.apache.org/jira/browse/SUREFIRE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14988568#comment-14988568 ] Robert Thornton edited comment on SUREFIRE-1191 at 11/4/15 1:15 AM: Tibor Digana This issue is most definitely a bug--not a request for a new feature. Support for this feature has been around for a long time. The following command works for every version of surefire from 2.4 to 2.18: mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test -Dtest=mypackage.MyTest It only stopped working with surefire:2.19: mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test -Dtest=mypackage.MyTest was (Author: rptmaestro): Tibor Digana This issue is most definitely a bug. The following command works for every version of surefire from 2.4 to 2.18: mvn org.apache.maven.plugins:maven-surefire-plugin:2.18:test -Dtest=mypackage.MyTest It only stopped working with surefire:2.19: mvn org.apache.maven.plugins:maven-surefire-plugin:2.19:test -Dtest=mypackage.MyTest > Run Single Test with Package Name Doesn't work > -- > > Key: SUREFIRE-1191 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1191 > Project: Maven Surefire > Issue Type: Wish >Affects Versions: 2.19 >Reporter: Gunnar Schmidt >Assignee: Tibor Digana > Fix For: 3.0 > > > Running the following command works: > mvn test -Dtest=MyTestCaseTest#myTest > This doesn't work (package name included): > mvn test -Dtest=my.package.name.MyTestCaseTest#myTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Comment: was deleted
(was: One line fix to perform interpolation on temporary model (tmpModel)
before attempting to read parent from remote repository.)
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that
any time a project property is requested (as in the above examples), it
should be interpolated based on the currently available project properties
even if the entire project hierarchy has not yet been loaded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Attachment: (was: MNG-5611-maven-model-builder.patch)
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that
any time a project property is requested (as in the above examples), it
should be interpolated based on the currently available project properties
even if the entire project hierarchy has not yet been loaded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Description:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
parent
groupIdorg.apache.maven.its.mng5611/groupId
artifactIdparent/artifactId
version0.1/version
/parent
properties
!--
Using properties allows repository definitions to be customized,
enabled/disabled, and tuned by child projects.
--
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
!-- Parent pom needs to be read from this repository --
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available project properties even if the
entire project hierarchy has not yet been loaded.
was:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available project properties even if the
entire project hierarchy has not yet been loaded.
Project properties are interpolated too late to be used in several parts of
the pom
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Description:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
parent
groupIdorg.apache.maven.its.mng5611/groupId
artifactIdparent/artifactId
version0.1/version
/parent
properties
!--
Using properties allows repository definitions to be customized,
enabled/disabled, and tuned by child projects
which is useful when you have several repositories that can be configured
with a few simple properties.
--
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
!-- Parent pom needs to be read from this repository --
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available project properties even if the
entire project hierarchy has not yet been loaded.
was:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
parent
groupIdorg.apache.maven.its.mng5611/groupId
artifactIdparent/artifactId
version0.1/version
/parent
properties
!--
Using properties allows repository definitions to be customized,
enabled/disabled, and tuned by child projects.
--
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
!-- Parent pom needs to be read from this repository --
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343689#comment-343689
]
Robert Thornton commented on MNG-5611:
--
In experimenting with a potential fix that would make the runtime interpolation
consistent with the effective pom, there are two aspects of how interpolation
is being done that makes a fix for this issue difficult.
First, the model is not interpolated until after all parent models have been
read (in {{DefaultModelBuilder.build}}) even though properties in the child
model override properties in the parent.
Applying the following line of code within the {{DefaultModelBuilder.build}}
method just before the call to {{readParent}} allows the parent to be resolved
from the remote repository using the properties defined in the project.
{code:java}
tmpModel = interpolateModel(tmpModel, request, problems); // MNG-5611
currentData = readParent( tmpModel, currentData.getSource(), request, problems
);
{code}
However, this exposes the second problem with how model interpolation is
implemented. Two test case fail due to the parent model's properties overriding
child properties as discovered from the following two integration tests:
{code}
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithoutProfiles
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithActiveProfiles
{code}
I believe the reason these tests fail is that after the properties of the child
project are interpolated (due to the potential fix in the code snippet above),
it somehow causes the parent properties to override the child properties in the
effective pom because all properties are interpolated at once instead of
on-demand. But since the child properties in this use case will override any
properties in the parent model, it seems pointless to wait for the parent model
to be loaded before these properties can be interpolated, especially when their
interpolation is necessary to resolving the parent.
I'm not sure if the current implementation for properties resolution will allow
for a resolution to this issue. But the problem, as I see it is that the
effective pom, which *does* resolve these properties as expected does not
accurately describe the model being used at the time the repositories are being
created by the implementation.
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
parent
groupIdorg.apache.maven.its.mng5611/groupId
artifactIdparent/artifactId
version0.1/version
/parent
properties
!--
Using properties allows repository definitions to be customized,
enabled/disabled, and tuned by child projects
which is useful when you have several repositories that can be configured
with a few simple properties.
--
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
!-- Parent pom needs to be read from this repository --
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=343689#comment-343689
]
Robert Thornton edited comment on MNG-5611 at 3/26/14 12:36 PM:
In experimenting with a potential fix that would make the runtime interpolation
consistent with the effective pom, there are two aspects of how interpolation
is being done that makes a fix for this issue difficult.
First, the model is not interpolated until after all parent models have been
read (in {{DefaultModelBuilder.build}}) even though properties in the child
model override properties in the parent.
Applying the following line of code within the {{DefaultModelBuilder.build}}
method just before the call to {{readParent}} allows the parent to be resolved
from the remote repository using the properties defined in the project.
{code:java}
tmpModel = interpolateModel(tmpModel, request, problems); // MNG-5611
currentData = readParent( tmpModel, currentData.getSource(), request, problems
);
{code}
However, this exposes the second problem with how model interpolation is
implemented. Two test case fail due to the parent model's properties overriding
child properties as discovered from the following two integration tests:
{code}
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithoutProfiles
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithActiveProfiles
{code}
I believe the reason these tests fail is that after the properties of the child
project are interpolated (due to the potential fix in the code snippet above),
it somehow causes the parent properties to override the child properties in the
effective pom because after all project models are loaded, the properties are
interpolated again en mass instead of on-demand. But since the child
properties in this use case would override any properties in the parent model
anyway, it seems pointless to wait for the parent model to be loaded before
these properties can be interpolated, especially when their interpolation is
necessary to resolving the parent.
I'm not sure if the current implementation for properties interpolation will
allow for a resolution to this issue. But the problem, as I see it, is that the
effective pom, which *does* resolve these properties as expected does not
accurately describe the model being used at the time the repositories are being
used by the implementation.
was (Author: rptmaestro):
In experimenting with a potential fix that would make the runtime interpolation
consistent with the effective pom, there are two aspects of how interpolation
is being done that makes a fix for this issue difficult.
First, the model is not interpolated until after all parent models have been
read (in {{DefaultModelBuilder.build}}) even though properties in the child
model override properties in the parent.
Applying the following line of code within the {{DefaultModelBuilder.build}}
method just before the call to {{readParent}} allows the parent to be resolved
from the remote repository using the properties defined in the project.
{code:java}
tmpModel = interpolateModel(tmpModel, request, problems); // MNG-5611
currentData = readParent( tmpModel, currentData.getSource(), request, problems
);
{code}
However, this exposes the second problem with how model interpolation is
implemented. Two test case fail due to the parent model's properties overriding
child properties as discovered from the following two integration tests:
{code}
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithoutProfiles
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithActiveProfiles
{code}
I believe the reason these tests fail is that after the properties of the child
project are interpolated (due to the potential fix in the code snippet above),
it somehow causes the parent properties to override the child properties in the
effective pom because all properties are interpolated at once instead of
on-demand. But since the child properties in this use case will override any
properties in the parent model, it seems pointless to wait for the parent model
to be loaded before these properties can be interpolated, especially when their
interpolation is necessary to resolving the parent.
I'm not sure if the current implementation for properties resolution will allow
for a resolution to this issue. But the problem, as I see it is that the
effective pom, which *does* resolve these properties as expected does not
accurately describe the model being used at the time the repositories are being
created by the implementation.
Project properties are interpolated too late to be used in several parts of
the pom
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
Robert Thornton created MNG-5611:
Summary: Project properties are interpolated too late to be used
in several parts of the pom
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Description:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available properties.
was:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process.
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Description:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available project properties even if the
entire project hierarchy has not yet been loaded.
was:
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that any
time a project property is requested (as in the above examples), it should be
interpolated based on the currently available properties.
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
I need projects that declare my pom as their parent to be able to define
project properties to customize essential
[jira] (MNG-5611) Project properties are interpolated too late to be used in several parts of the pom
[
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Thornton updated MNG-5611:
-
Attachment: MNG-5611-maven-model-builder.patch
One line fix to perform interpolation on temporary model (tmpModel) before
attempting to read parent from remote repository.
Project properties are interpolated too late to be used in several parts of
the pom
---
Key: MNG-5611
URL: https://jira.codehaus.org/browse/MNG-5611
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Robert Thornton
Attachments: MNG-5611-maven-model-builder.patch
I need projects that declare my pom as their parent to be able to define
project properties to customize essential components of their build, such as
repositories, pluginRepositories, and distributionManagement.
For example:
{code:xml}
properties
repo.urlhttp://repo.mysite.com/nexus/content/repo.url
repo.releases.enabledtrue/repo.releases.enabled
repo.snapshots.enabledfalse/repo.snapshots.enabled
repo.updatedaily/repo.update
/properties
repositories
repository
idmy-repo/id
nameMy Repository/name
url${repo.url}/groups/main-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idmy-plugin-repo/id
nameMy Plugin Repository/name
url${repo.url}/groups/plugin-repo/url
releases
enabled${repo.releases.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/releases
snapshots
enabled${repo.snapshots.enabled}/enabled
updatePolicy${repo.update}/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
{code}
The bug is that the effective pom correctly shows these properties as being
interpolated for the above repositories, however the Aether RemoteRepository
objects for the above definitions are created before the pom's properties are
interpolated. This results in unexpected behavior that can only be understood
by attaching a debugger to the Maven build process. The above example fails,
for example, if the above pom's parent is in the repository whose properties
haven't been interpolated yet.
The way I believe the properties interpolation process should work is that
any time a project property is requested (as in the above examples), it
should be interpolated based on the currently available project properties
even if the entire project hierarchy has not yet been loaded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
