[jira] [Comment Edited] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149846#comment-16149846
]
S L edited comment on MNG-6278 at 9/1/17 12:48 AM:
---
Just as a side-node:
The maven-surefire-plugin would be affected by this as well when using the
configuration in [Skipping
Tests](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_Tests).
However when defining an additional property and providing this property as
argument for the plugin configuration like outlined in [Skipping by
Default](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_by_Default)
everything starts working again as expected.
Attached is another sample project where one can reproduce with the
maven-surefire-plugin itself:
> mvn clean package -PdemoConfigUnSet -DskipTests=true
Tests are skipped as expected since configuration is NOT set
> mvn clean package -PdemoConfigSet -DskipTests=true
Test will be executed and fail since the Test available has an `Assert.fail`
Also note that this issue has a limited impact on the surefire-plugin.
The reason for this is that it uses as a configuration the value
and via command line maven.test.skip and if you check closely the source code
it actually ends up in two distinct parameters:
* via configuration see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L160
* via command line maven.test.skip see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L178
In the end they check all possible ways to skip the plugin:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L360
was (Author: thesnoozer):
Just as a side-node:
The maven-surefire-plugin would be affected by this as well when using the
configuration in [Skipping
Tests](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_Tests).
However when defining an additional property and providing this property as
argument for the plugin configuration like outlined in [Skipping by
Default](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_by_Default)
everything starts working again as expected.
Attached is another sample project where one can reproduce with the
maven-surefire-plugin itself:
> mvn clean package -PdemoConfigUnSet -DskipTests=true
Tests are skipped as expected since configuration is NOT set
> mvn clean package -PdemoConfigSet -DskipTests=true
Test will be executed and fail since the Test available has an `Assert.fail`
Also note that this issue has a limited impact on the surefire-plugin.
The reason for this is that it uses as a configuration the value
and via command line maven.test.skip and if you check closely the source code
it actually two distinct parameters:
* via configuration see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L160
* via command line maven.test.skip see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L178
In the end they check all possible ways to skip the plugin:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L360
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define a value of this property inside the
> configuration-tag of the plugin and also provide an option via the
> commandline e.g. `-Dmaven.buildHelperMojo.skip=true` the value provided by
> commandline is getting ign
[jira] [Updated] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S L updated MNG-6278:
-
Description:
Hi I have a strange problem with a property definition inside an
@Parameter-Annotation.
Pretty much the configuration inside the plugin is as the following:
{code:java}
@Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
private boolean skip;
{code}
The original reference for this can be found here:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
Regardless whenever I define a value of this property inside the
configuration-tag of the plugin and also provide an option via the commandline
e.g. `-Dmaven.buildHelperMojo.skip=true` the value provided by commandline is
getting ignored.
I have attached a sample project where the issue can be reproduced with the
following:
> mvn clean install && mvn clean initialize -PdemoConfigSet
> -Dmaven.buildHelperMojo.skip=true
- doesn't work since it has the configuration-tag set
> mvn clean install && mvn clean initialize -PdemoConfigUnSet
> -Dmaven.buildHelperMojo.skip=true
- works as expected since it has the configuration-tag NOT set
was:
Hi I have a strange problem with a property definition inside an
@Parameter-Annotation.
Pretty much the configuration inside the plugin is as the following:
{code:java}
@Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
private boolean skip;
{code}
The original reference for this can be found here:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
Regardless whenever I define the configuren of this property inside the
configuration of the plugin and also provide an option via the commandline e.g.
`-Dmaven.buildHelperMojo.skip=true` the value provided by commandline is
getting ignored.
I have attached a sample project where the issue can be reproduced with the
following:
> mvn clean install && mvn clean initialize -PdemoConfigSet
> -Dmaven.buildHelperMojo.skip=true
- doesn't work since it has the configuration-tag set
> mvn clean install && mvn clean initialize -PdemoConfigUnSet
> -Dmaven.buildHelperMojo.skip=true
- works as expected since it has the configuration-tag NOT set
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define a value of this property inside the
> configuration-tag of the plugin and also provide an option via the
> commandline e.g. `-Dmaven.buildHelperMojo.skip=true` the value provided by
> commandline is getting ignored.
> I have attached a sample project where the issue can be reproduced with the
> following:
> > mvn clean install && mvn clean initialize -PdemoConfigSet
> > -Dmaven.buildHelperMojo.skip=true
> - doesn't work since it has the configuration-tag set
> > mvn clean install && mvn clean initialize -PdemoConfigUnSet
> > -Dmaven.buildHelperMojo.skip=true
> - works as expected since it has the configuration-tag NOT set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S L updated MNG-6278:
-
Description:
Hi I have a strange problem with a property definition inside an
@Parameter-Annotation.
Pretty much the configuration inside the plugin is as the following:
{code:java}
@Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
private boolean skip;
{code}
The original reference for this can be found here:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
Regardless whenever I define the configuren of this property inside the
configuration of the plugin and also provide an option via the commandline e.g.
`-Dmaven.buildHelperMojo.skip=true` the value provided by commandline is
getting ignored.
I have attached a sample project where the issue can be reproduced with the
following:
> mvn clean install && mvn clean initialize -PdemoConfigSet
> -Dmaven.buildHelperMojo.skip=true
- doesn't work since it has the configuration-tag set
> mvn clean install && mvn clean initialize -PdemoConfigUnSet
> -Dmaven.buildHelperMojo.skip=true
- works as expected since it has the configuration-tag NOT set
was:
Hi I have a strange problem with a property definition inside an
@Parameter-Annotation.
Pretty much the configuration inside the plugin is as the following:
{code:java}
@Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
private boolean skip;
{code}
The original reference for this can be found here:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
Regardless whenever I define the configure the property inside the
configuration of the plugin the commandline option e.g.
`-Dmaven.buildHelperMojo.skip=true` is getting ignored.
I have attached a sample project where the issue can be reproduced with the
following:
> mvn clean install && mvn clean initialize -PdemoConfigSet
> -Dmaven.buildHelperMojo.skip=true
- doesn't work since it has the configuration-tag set
> mvn clean install && mvn clean initialize -PdemoConfigUnSet
> -Dmaven.buildHelperMojo.skip=true
- works as expected since it has the configuration-tag NOT set
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define the configuren of this property inside the
> configuration of the plugin and also provide an option via the commandline
> e.g. `-Dmaven.buildHelperMojo.skip=true` the value provided by commandline is
> getting ignored.
> I have attached a sample project where the issue can be reproduced with the
> following:
> > mvn clean install && mvn clean initialize -PdemoConfigSet
> > -Dmaven.buildHelperMojo.skip=true
> - doesn't work since it has the configuration-tag set
> > mvn clean install && mvn clean initialize -PdemoConfigUnSet
> > -Dmaven.buildHelperMojo.skip=true
> - works as expected since it has the configuration-tag NOT set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S L updated MNG-6278:
-
Attachment: SampleProject_v2.zip
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define the configure the property inside the
> configuration of the plugin the commandline option e.g.
> `-Dmaven.buildHelperMojo.skip=true` is getting ignored.
> I have attached a sample project where the issue can be reproduced with the
> following:
> > mvn clean install && mvn clean initialize -PdemoConfigSet
> > -Dmaven.buildHelperMojo.skip=true
> - doesn't work since it has the configuration-tag set
> > mvn clean install && mvn clean initialize -PdemoConfigUnSet
> > -Dmaven.buildHelperMojo.skip=true
> - works as expected since it has the configuration-tag NOT set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S L updated MNG-6278:
-
Attachment: (was: SampleProject_v2.zip)
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define the configure the property inside the
> configuration of the plugin the commandline option e.g.
> `-Dmaven.buildHelperMojo.skip=true` is getting ignored.
> I have attached a sample project where the issue can be reproduced with the
> following:
> > mvn clean install && mvn clean initialize -PdemoConfigSet
> > -Dmaven.buildHelperMojo.skip=true
> - doesn't work since it has the configuration-tag set
> > mvn clean install && mvn clean initialize -PdemoConfigUnSet
> > -Dmaven.buildHelperMojo.skip=true
> - works as expected since it has the configuration-tag NOT set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6278) property inside @Parameter-Annotation is being ignored if it is also set inside the configuration of the Plugin
[
https://issues.apache.org/jira/browse/MNG-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
S L updated MNG-6278:
-
Attachment: SampleProject_v2.zip
Just as a side-node:
The maven-surefire-plugin would be affected by this as well when using the
configuration in [Skipping
Tests](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_Tests).
However when defining an additional property and providing this property as
argument for the plugin configuration like outlined in [Skipping by
Default](https://maven.apache.org/surefire/maven-surefire-plugin/examples/skipping-tests.html#Skipping_by_Default)
everything starts working again as expected.
Attached is another sample project where one can reproduce with the
maven-surefire-plugin itself:
> mvn clean package -PdemoConfigUnSet -DskipTests=true
Tests are skipped as expected since configuration is NOT set
> mvn clean package -PdemoConfigSet -DskipTests=true
Test will be executed and fail since the Test available has an `Assert.fail`
Also note that this issue has a limited impact on the surefire-plugin.
The reason for this is that it uses as a configuration the value
and via command line maven.test.skip and if you check closely the source code
it actually two distinct parameters:
* via configuration see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L160
* via command line maven.test.skip see
https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L178
In the end they check all possible ways to skip the plugin:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L360
> property inside @Parameter-Annotation is being ignored if it is also set
> inside the configuration of the Plugin
> ---
>
> Key: MNG-6278
> URL: https://issues.apache.org/jira/browse/MNG-6278
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.5, 3.3.9, 3.5.0
>Reporter: S L
>Priority: Critical
> Attachments: SampleProject_v2.zip, SampleProject.zip
>
>
> Hi I have a strange problem with a property definition inside an
> @Parameter-Annotation.
> Pretty much the configuration inside the plugin is as the following:
> {code:java}
> @Parameter(property = "maven.buildHelperMojo.skip", defaultValue = "false")
> private boolean skip;
> {code}
> The original reference for this can be found here:
> https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Parameters
> Regardless whenever I define the configure the property inside the
> configuration of the plugin the commandline option e.g.
> `-Dmaven.buildHelperMojo.skip=true` is getting ignored.
> I have attached a sample project where the issue can be reproduced with the
> following:
> > mvn clean install && mvn clean initialize -PdemoConfigSet
> > -Dmaven.buildHelperMojo.skip=true
> - doesn't work since it has the configuration-tag set
> > mvn clean install && mvn clean initialize -PdemoConfigUnSet
> > -Dmaven.buildHelperMojo.skip=true
> - works as expected since it has the configuration-tag NOT set
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[ https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149718#comment-16149718 ] ASF GitHub Bot commented on SUREFIRE-1383: -- Github user owenfarrell commented on the issue: https://github.com/apache/maven-surefire/pull/157 @Tibor17 I see what you're going for, that makes sense. I've update my PR to just include IT contents now, with an improved IT that emulates a scenario where working copy changes are made (i.e. install a multi-module project, modify the contents to add more tests, test the modified contents). If your solution gets my IT PR to pass, I think the solution will cover my bona fide scenarios. > dependenciesToScan Does Not Leverage Classpath Elements > > > Key: SUREFIRE-1383 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Owen Farrell >Assignee: Tibor Digana > Fix For: 2.20.1 > > Attachments: scanned-dependencies-sample.zip > > Time Spent: 48h > Remaining Estimate: 24h > > The configuration attribute relies solely on installed > artifacts. This is an issue when the targeted dependencies were built as part > of the current session. The net result is that stale artifacts are used (i.e. > if the dependency has changed since it was last installed) or the tests are > not executed at all (if the dependency has not been previously installed. > Attached is a sample project that illustrates this issue: > Given I have a multi-module project >And the first module built includes test classes as part of the project > artifact >And subsequent modules scan the first for unit tests to execute > When I execute the _*test*_ goal (prior to any install) > Then the build should succeed >And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[
https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149634#comment-16149634
]
ASF GitHub Bot commented on SUREFIRE-1383:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/157
@owenfarrell
My tests passed on this code. I have to continue to develop and refactor
more.
List testDepends = project.getTestArtifacts();
removeReactorDependencies( session.getSortedProjects(),
testDepends.iterator() );
List dependenciesToScan = filter( testDepends,
asList( getDependenciesToScan() ) );
TestListResolver testFilter = getIncludedAndExcludedTests();
DefaultScanResult scanResult = new DependencyScanner(
dependenciesToScan, testFilter ).scan();
for ( MavenProject project : session.getSortedProjects() )
{
if ( !"pom".equals( project.getPackaging() ) &&
!containsProjectArtifact( testDepends, project ) )
{
// zapracuj getDependenciesToScan()
File reactorChildProjectOutputDir = new File(
project.getBuild().getOutputDirectory() );
if ( reactorChildProjectOutputDir.isDirectory() )
{
DirectoryScanner scanner = new
DirectoryScanner( reactorChildProjectOutputDir, testFilter );
scanResult = scanResult.append( scanner.scan()
);
}
}
}
> dependenciesToScan Does Not Leverage Classpath Elements
>
>
> Key: SUREFIRE-1383
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1383
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Owen Farrell
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: scanned-dependencies-sample.zip
>
> Time Spent: 48h
> Remaining Estimate: 24h
>
> The configuration attribute relies solely on installed
> artifacts. This is an issue when the targeted dependencies were built as part
> of the current session. The net result is that stale artifacts are used (i.e.
> if the dependency has changed since it was last installed) or the tests are
> not executed at all (if the dependency has not been previously installed.
> Attached is a sample project that illustrates this issue:
> Given I have a multi-module project
>And the first module built includes test classes as part of the project
> artifact
>And subsequent modules scan the first for unit tests to execute
> When I execute the _*test*_ goal (prior to any install)
> Then the build should succeed
>And tests should be executed with each module
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149248#comment-16149248 ] Robert Scholte commented on MNG-6216: - bq. were you running parallel builds or two maven sessions concurrently? (Perhaps your IDE was downloading POMs concurrently with your maven CLI build?) bq. I am now wondering if there could be some IDE background downloading and not doing in a concurrent safe way IDE (probably Eclipse at that time) open and running Maven via commandline. So yes, there's a chance that 2 processes are trying to do the same thing, but they are somehow appended at the end. bq. The rebased https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/MNG-6216/5/pipeline which has the plexus update should handle the doubled pom's (though it would be good to find out where they were originating) That's the wrong conclusion. It contains a fix for the AIOOBE when there's a XML process instruction in a large pom file. So we have the same exception, but with different causes. > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149091#comment-16149091 ] Matthew Janssen commented on MNG-6216: -- [~stephenc] As far as I know, our company uses Nexus as our repository. But I don't know a whole lot about it since that's a completely separate org that handles our build factories. And +1 on resolving the issue in the short term and identifying the problem over the long term. > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148765#comment-16148765 ] Stephen Connolly commented on MNG-6216: --- [~rfscholte] we need to decide whether to resolve this issue or not. I propose we resolve this issue and spin off a task to try and identify the root cause of the corrupted POMs > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6037: -- Fix Version/s: (was: wontfix-candidate) > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (MNG-5988) Dependency mediation should prioritize transitive dependencies based on scope.
[
https://issues.apache.org/jira/browse/MNG-5988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-5988:
---
Assignee: (was: Christian Schulte)
Re-opening as not actually fixed after 3.5.0 reset
> Dependency mediation should prioritize transitive dependencies based on scope.
> --
>
> Key: MNG-5988
> URL: https://issues.apache.org/jira/browse/MNG-5988
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
>Reporter: Jostein Gogstad
>Priority: Critical
> Fix For: needing-scrub-3.4.0-fallout
>
> Attachments: Collected.svg, MNG-5988.zip, PRE.svg, Resolved.svg
>
>
> The
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> states that dependency mediation only supports "nearest definition",
> regardless of the scope of the parent dependency.
> If both compile- and test scoped dependencies shares the same transitive
> dependency, the test-scoped one will win if it has shallower depth. That in
> turn will lead to runtime exceptions since the transitive dependency is no
> longer on the classpath.
> Take the following pom from a typical [Spring
> Boot|http://projects.spring.io/spring-boot/] application. Since the
> {{camel-test-spring}} dependency also depends on spring, it wins and Spring
> is no longer available to the application at runtime.
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.example
> bugreport
> jar
> 1.0.0-SNAPSHOT
>
>
> org.springframework.boot
> spring-boot-starter-web
> 1.3.2.RELEASE
>
>
> org.apache.camel
> camel-test-spring
> 2.16.2
> test
>
>
>
> {code}
> Now look for {{spring-beans}} or {{spring-context}} in the following
> dependency graphs:
> {code:xml|title=mvn dependency:tree (with camel-test-spring)}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ bugreport ---
> [INFO] com.example:bugreport:jar:1.0.0-SNAPSHOT
> [INFO] +-
> org.springframework.boot:spring-boot-starter-web:jar:1.3.2.RELEASE:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.springframework.boot:spring-boot:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-autoconfigure:jar:1.3.2.RELEASE:compile
> [INFO] | | +-
> org.springframework.boot:spring-boot-starter-logging:jar:1.3.2.RELEASE:compile
> [INFO] | | | +- ch.qos.logback:logback-classic:jar:1.1.3:compile
> [INFO] | | | | \- ch.qos.logback:logback-core:jar:1.1.3:compile
> [INFO] | | | +- org.slf4j:jcl-over-slf4j:jar:1.7.13:compile
> [INFO] | | | +- org.slf4j:jul-to-slf4j:jar:1.7.13:compile
> [INFO] | | | \- org.slf4j:log4j-over-slf4j:jar:1.7.13:compile
> [INFO] | | \- org.yaml:snakeyaml:jar:1.16:runtime
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:1.3.2.RELEASE:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.0.30:compile
> [INFO] | | +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.0.30:compile
> [INFO] | | +-
> org.apache.tomcat.embed:tomcat-embed-logging-juli:jar:8.0.30:compile
> [INFO] | | \-
> org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.0.30:compile
> [INFO] | +-
> org.springframework.boot:spring-boot-starter-validation:jar:1.3.2.RELEASE:compile
> [INFO] | | \- org.hibernate:hibernate-validator:jar:5.2.2.Final:compile
> [INFO] | | +- javax.validation:validation-api:jar:1.1.0.Final:compile
> [INFO] | | +- org.jboss.logging:jboss-logging:jar:3.2.1.Final:compile
> [INFO] | | \- com.fasterxml:classmate:jar:1.1.0:compile
> [INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.6.5:compile
> [INFO] | | +-
> com.fasterxml.jackson.core:jackson-annotations:jar:2.6.0:compile
> [INFO] | | \- com.fasterxml.jackson.core:jackson-core:jar:2.6.5:compile
> [INFO] | +- org.springframework:spring-web:jar:4.2.4.RELEASE:compile
> [INFO] | \- org.springframework:spring-webmvc:jar:4.2.4.RELEASE:compile
> [INFO] \- org.apache.camel:camel-test-spring:jar:2.16.2:test
> [INFO]+- org.apache.camel:camel-test:jar:2.16.2:test
> [INFO]| +- org.apache.camel:camel-core:jar:2.16.2:test
> [INFO]| | \- org.slf4j:slf4j-api:jar:1.6.6:compile
> [INFO]| \- junit:junit:jar:4.11:test
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.3:test
> [INFO]+- org.apache.camel:camel-spring:jar:2.16.2:test
> [INFO]+- org.springframework:spring-test:
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148752#comment-16148752 ] Hudson commented on MNG-6216: - SUCCESS: Integrated in Jenkins build maven-3.x #1667 (See [https://builds.apache.org/job/maven-3.x/1667/]) [MNG-6216] ArrayIndexOutOfBoundsException when parsing POM o Upgraded (stephen.alan.connolly: [http://git-wip-us.apache.org/repos/asf/?p=maven.git&a=commit&h=c9a288d8b1090fa957d6caccc12f0bf13bb5e267]) * (edit) pom.xml > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly resolved MNG-6037. --- Resolution: Won't Fix > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: wontfix-candidate > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5639:
--
Fix Version/s: (was: 3.5.1-candidate)
(was: 3.2.2)
3.5.x-candidate
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 3.5.x-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-2893: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: https://issues.apache.org/jira/browse/MNG-2893 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Fix For: 3.2.x, 3.5.x-candidate > > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5527:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.x-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6112: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte > Fix For: 3.5.x-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5600:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.x-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-4347) import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
[ https://issues.apache.org/jira/browse/MNG-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-4347: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > import-scoped dependencies of direct dependencies are not resolved using > profile modifications from settings.xml > > > Key: MNG-4347 > URL: https://issues.apache.org/jira/browse/MNG-4347 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies, General, > Profiles, Settings >Affects Versions: 2.2.1 >Reporter: John Casey >Priority: Critical > Fix For: 2.2.2, 3.5.x-candidate > > > Given: > * project A lists project B as a dependency > * project B lists project C as an import-scoped entry in dependencyManagement > * project B's dependency version for project C is a SNAPSHOT > * the user's settings.xml file modifies the definition of the central > repository to enable searching for SNAPSHOT artifacts. > When project A's dependency POMs are retrieved as part of collecting the > transitive dependency closure for A, B's project instance is built. During > this process, the POM for project C should be retrieved from central > (according to the modifications in settings.xml). However, the profile > information from the settings.xml is never applied to project B's POM, and > never modifies the central repository definition found there. Since the > default definition for the repository 'central' from the super POM has > snapshots disabled, project C's POM cannot be found, and the build fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-5984:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.5.x-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-5359: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.x-candidate > > Attachments: binding-test.zip, MNG-5359-IT.patch > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.
[ https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6114: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Elements from the global settings should be ordered before elements from the > user settings. > --- > > Key: MNG-6114 > URL: https://issues.apache.org/jira/browse/MNG-6114 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte > Fix For: 3.5.x-candidate > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6188) Console color not properly reset when interrupting build process
[ https://issues.apache.org/jira/browse/MNG-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly updated MNG-6188: -- Fix Version/s: (was: 3.5.1-candidate) 3.5.x-candidate > Console color not properly reset when interrupting build process > > > Key: MNG-6188 > URL: https://issues.apache.org/jira/browse/MNG-6188 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.5.0-alpha-1 >Reporter: Robert Scholte > Fix For: 3.5.x-candidate > > Attachments: jansi-bug.PNG > > > When interrupting the build process for some reason, it could happen that > console has still a color assigned. > For a possible result, see the attachment (most of mint should have been > white) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI
[
https://issues.apache.org/jira/browse/MNG-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6069:
--
Fix Version/s: (was: 3.5.1-candidate)
3.5.x-candidate
> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.x-candidate
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information"
> ).build()
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148748#comment-16148748 ] Stephen Connolly commented on MNG-6216: --- I've merged https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=c9a288d8b1090fa957d6caccc12f0bf13bb5e267 given that the build passed > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148733#comment-16148733 ] Stephen Connolly commented on MNG-6216: --- [~rfscholte] were you running parallel builds or two maven sessions concurrently? (Perhaps your IDE was downloading POMs concurrently with your maven CLI build?) The rebased https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/MNG-6216/5/pipeline which has the plexus update should handle the doubled pom's (though it would be good to find out where they were originating) I am now wondering if there could be some IDE background downloading and not doing in a concurrent safe way > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148710#comment-16148710 ] Robert Scholte commented on MNG-6216: - [~stephenc] I've seen it once when I was connected to a Nexus Instance. The `pom.xml` was correct in the repository manager, but "doubled" in my local repository. > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MNG-6195) Use consistent quoting forms in mvn launcher script
[
https://issues.apache.org/jira/browse/MNG-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly closed MNG-6195.
-
> Use consistent quoting forms in mvn launcher script
> ---
>
> Key: MNG-6195
> URL: https://issues.apache.org/jira/browse/MNG-6195
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0-alpha-1, 3.5.0-beta-1
>Reporter: Stephen Connolly
>Assignee: Stephen Connolly
> Fix For: 3.5.0
>
>
> We have different forms of quoting in the shell script. We should pick a
> consistent policy and follow that.
> Specific areas of concern around backticks and {{$(...)}}
> Solaris 10 is known to have a true BourneShell which does not understand
> {{$(...)}} but the backtick style is very hard to quote effectively
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148700#comment-16148700 ] Stephen Connolly edited comment on MNG-6216 at 8/31/17 9:17 AM: [~mttjj] What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point was (Author: stephenc): What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148700#comment-16148700 ] Stephen Connolly commented on MNG-6216: --- What mirror software are you using? There are some mirrors available that have a "feature" to rewrite the pom.xml on the fly and remove and inject things in the poms, e.g. removing the section or even injecting a replacement one. IIRC neither nexus nor archivia have that "feature" (or if they have the feature they do not have it enabled by default) but if you are using the other one, it may be a useful data-point > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy > Fix For: 3.5.1 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148694#comment-16148694
]
Stephen Connolly commented on MNG-6275:
---
Pulling back in scope for 3.5.1 as we look to have a candidate viable fix:
https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/activity?branch=mng-6275
https://github.com/apache/maven/compare/mng-6275
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reassigned MNG-6275:
-
Assignee: Stephen Connolly (was: Robert Scholte)
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Stephen Connolly
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6275:
--
Fix Version/s: (was: 3.6.x-candidate)
3.5.1
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
