[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108224#comment-16108224 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/161#discussion_r130497860 --- Diff: surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml --- @@ -0,0 +1,61 @@ + + +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/xsd/maven-4.0.0.xsd;> + 4.0.0 + + org.apache.maven.plugins.surefire + surefire-test-classpath-provider + 1.0-SNAPSHOT + Test provider + + +2.21-SNAPSHOT --- End diff -- Sorry about that - hadn't noticed that it wasn't specified. Added it to both the provider and the test project. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108153#comment-16108153 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/161#discussion_r130488490 --- Diff: surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml --- @@ -0,0 +1,61 @@ + + +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/xsd/maven-4.0.0.xsd;> + 4.0.0 + + org.apache.maven.plugins.surefire + surefire-test-classpath-provider + 1.0-SNAPSHOT + Test provider + + +2.21-SNAPSHOT --- End diff -- You should specify parent pom ``` org.apache.maven.surefire it-parent 1.0 ../pom.xml ``` > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107944#comment-16107944 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on the issue: https://github.com/apache/maven-surefire/pull/161 Thanks - I made the fixes you suggested above, and confirmed that the build passed on `mvn clean install -P run-its` > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107922#comment-16107922
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
ok, take your time. No worries. Just rebase the PR after your team finished
the release. Surefire need some week to make release as well.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107909#comment-16107909
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user mpkorstanje commented on the issue:
https://github.com/apache/maven-surefire/pull/150
Yes! We're satisfied with the current state of the code and more people are
now able to make releases. As such we're finalizing the release at the moment,
I expect we'll do a couple of last minute bug fixes but that should be it. I
can't make any promises about a time frame but I reckon it will be soon now.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[
https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107883#comment-16107883
]
ASF GitHub Bot commented on SUREFIRE-1396:
--
Github user Tibor17 commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/161#discussion_r130447743
--- Diff:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
---
@@ -2755,7 +2755,16 @@ public Classpath getProviderClasspath()
throws ArtifactResolutionException, ArtifactNotFoundException
{
final Map pluginArtifactMap =
getPluginArtifactMap();
-Artifact plugin = pluginArtifactMap.get(
"org.apache.maven.plugins:maven-surefire-plugin" );
+Class c = AbstractSurefireMojo.this.getClass();
+Artifact plugin;
+if ( c.getName().equals(
"org.apache.maven.plugin.failsafe.IntegrationTestMojo" ) )
--- End diff --
I guess this is in method `getProviderClasspath()`
Please split the method in two. First it would call `protected abstract
Artifact getMojoArtifact()` and then the original statement `return
dependencyResolver.addProviderToClasspath( pluginArtifactMap, plugin );` where
`plugin` is `Artifact`. Then force both subclasse to implement
`getMojoArtifact` which means surefire mojo will implement it as follows:
`final Map pluginArtifactMap = getPluginArtifactMap();
Artifact plugin = pluginArtifactMap.get(
"org.apache.maven.plugins:maven-surefire-plugin" );`.
> Provider class path is incorrect for custom provider in Failsafe
>
>
> Key: SUREFIRE-1396
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1396
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Jonathan Bell
>
> Hi,
> When using a custom Surefire provider with Surefire (not Failsafe), the
> "provider classpath" contains only the provider and surefire-api. However,
> when using a custom provider with Failsafe, the provider class path ends up
> including a lot more... it seems like perhaps all plugins that are loaded?
> This has caused some mayhem for me when using a custom provider in projects
> that use a specific version of SLF4J... because then failsafe forces 1.5.6 to
> be loaded (from this process of incorrectly finding the custom provider),
> causing a crash.
> It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the
> Surefire plugin hardcoded, which isn't correct when it's actually Failsafe).
> I've got a patched fork of master on GitHub
> (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2)
> that fixes it and an integration test that demonstrates the flaw. I am not
> 100% sure on the formatting of the integration test (i.e., I am opening a
> JIRA ticket so that I suppose I can name it under the JIRA issue? How should
> I specify the current version of surefire in the integration test package?) -
> if the fix is welcome against master I'd be happy to open a PR on GitHub. I
> am also happy to merge against a different branch if it's more helpful.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107877#comment-16107877 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user jon-bell commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/161#discussion_r130447222 --- Diff: surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml --- @@ -0,0 +1,61 @@ + + +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/xsd/maven-4.0.0.xsd;> + 4.0.0 + + org.apache.maven.plugins.surefire + surefire-test-classpath-provider + 1.0-SNAPSHOT + Test provider + + +2.21-SNAPSHOT --- End diff -- I did a `mvn verify` from the top level. I will do a `mvn install -P run-its` now. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[
https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107873#comment-16107873
]
ASF GitHub Bot commented on SUREFIRE-1396:
--
Github user jon-bell commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/161#discussion_r130446456
--- Diff:
surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml
---
@@ -0,0 +1,61 @@
+
+
+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/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+ org.apache.maven.plugins.surefire
+ surefire-test-classpath-provider
+ 1.0-SNAPSHOT
+ Test provider
+
+
+2.21-SNAPSHOT
+
+
+
+ org.apache.maven.surefire
+ surefire-api
+ ${surefire.version}
+
+
+
+
+
+
+src/main/resources/META-INF
+META-INF
+
+
+
+
+org.apache.maven.plugins
+maven-compiler-plugin
--- End diff --
Thanks. I will clean this up. FYI, the entire pom.xml is copied from the
[SUREFIRE-141 IT
pom.xml](https://github.com/apache/maven-surefire/blob/cba4adb1b93002c5b4bb2d2f22f461cc53bd8738/surefire-integration-tests/src/test/resources/surefire-141-pluggableproviders-provider/pom.xml).
> Provider class path is incorrect for custom provider in Failsafe
>
>
> Key: SUREFIRE-1396
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1396
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Jonathan Bell
>
> Hi,
> When using a custom Surefire provider with Surefire (not Failsafe), the
> "provider classpath" contains only the provider and surefire-api. However,
> when using a custom provider with Failsafe, the provider class path ends up
> including a lot more... it seems like perhaps all plugins that are loaded?
> This has caused some mayhem for me when using a custom provider in projects
> that use a specific version of SLF4J... because then failsafe forces 1.5.6 to
> be loaded (from this process of incorrectly finding the custom provider),
> causing a crash.
> It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the
> Surefire plugin hardcoded, which isn't correct when it's actually Failsafe).
> I've got a patched fork of master on GitHub
> (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2)
> that fixes it and an integration test that demonstrates the flaw. I am not
> 100% sure on the formatting of the integration test (i.e., I am opening a
> JIRA ticket so that I suppose I can name it under the JIRA issue? How should
> I specify the current version of surefire in the integration test package?) -
> if the fix is welcome against master I'd be happy to open a PR on GitHub. I
> am also happy to merge against a different branch if it's more helpful.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107865#comment-16107865 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/161#discussion_r130445317 --- Diff: surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml --- @@ -0,0 +1,61 @@ + + +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/xsd/maven-4.0.0.xsd;> + 4.0.0 + + org.apache.maven.plugins.surefire + surefire-test-classpath-provider + 1.0-SNAPSHOT + Test provider + + +2.21-SNAPSHOT + + + + org.apache.maven.surefire + surefire-api --- End diff -- Why? See the `build.log` in target and you will see project version and all necessary dependencies hidden in the fork transitive deps. > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[
https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107867#comment-16107867
]
ASF GitHub Bot commented on SUREFIRE-1396:
--
Github user Tibor17 commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/161#discussion_r130445462
--- Diff:
surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml
---
@@ -0,0 +1,61 @@
+
+
+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/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+ org.apache.maven.plugins.surefire
+ surefire-test-classpath-provider
+ 1.0-SNAPSHOT
+ Test provider
+
+
+2.21-SNAPSHOT
+
+
+
+ org.apache.maven.surefire
+ surefire-api
+ ${surefire.version}
+
+
+
+
+
+
+src/main/resources/META-INF
+META-INF
+
+
+
+
+org.apache.maven.plugins
+maven-compiler-plugin
--- End diff --
This plugin is again in parent pom. Not necessary here.
> Provider class path is incorrect for custom provider in Failsafe
>
>
> Key: SUREFIRE-1396
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1396
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Jonathan Bell
>
> Hi,
> When using a custom Surefire provider with Surefire (not Failsafe), the
> "provider classpath" contains only the provider and surefire-api. However,
> when using a custom provider with Failsafe, the provider class path ends up
> including a lot more... it seems like perhaps all plugins that are loaded?
> This has caused some mayhem for me when using a custom provider in projects
> that use a specific version of SLF4J... because then failsafe forces 1.5.6 to
> be loaded (from this process of incorrectly finding the custom provider),
> causing a crash.
> It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the
> Surefire plugin hardcoded, which isn't correct when it's actually Failsafe).
> I've got a patched fork of master on GitHub
> (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2)
> that fixes it and an integration test that demonstrates the flaw. I am not
> 100% sure on the formatting of the integration test (i.e., I am opening a
> JIRA ticket so that I suppose I can name it under the JIRA issue? How should
> I specify the current version of surefire in the integration test package?) -
> if the fix is welcome against master I'd be happy to open a PR on GitHub. I
> am also happy to merge against a different branch if it's more helpful.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107861#comment-16107861 ] ASF GitHub Bot commented on SUREFIRE-1396: -- Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/161#discussion_r130444914 --- Diff: surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml --- @@ -0,0 +1,61 @@ + + +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/xsd/maven-4.0.0.xsd;> + 4.0.0 + + org.apache.maven.plugins.surefire + surefire-test-classpath-provider + 1.0-SNAPSHOT + Test provider + + +2.21-SNAPSHOT --- End diff -- Pls do not use this property. It comes from [parent pom](https://github.com/apache/maven-surefire/blob/master/surefire-integration-tests/src/test/resources/pom.xml). Did you run the build like this `mvn install -P run-its`? > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107856#comment-16107856
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@mpkorstanje
You changed something in your code or what happened that snapshot was not
available?
Is the release 2.0.0 coming soon?
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107492#comment-16107492 ] Curtis Rueden edited comment on MNG-5761 at 7/31/17 4:01 PM: - I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, projects depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. was (Author: ctrueden): I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, project depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107495#comment-16107495 ] Curtis Rueden commented on MNG-6141: I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, projects depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107492#comment-16107492 ] Curtis Rueden commented on MNG-5761: I also ran into this issue, and posted [an MCVE gist|https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3] illustrating it. In my view, if a library L believes it depends on component X at a particular version, project depending on L should also inherit component X at that same version. See also [this SO post|https://stackoverflow.com/q/45041888/1207769]. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107376#comment-16107376
]
Med Reda edited comment on MRELEASE-911 at 7/31/17 2:41 PM:
When i use release:prepare with release:perform it works fin and it creates a
tag otherwise i need a branch instead of tag with this command i have the same
issue :
(mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
was (Author: inforedaster):
When i use release:prepare with release:perform it works fin and it creates a
tag otherwise i need a branch instead of tag with this command i have the same
issue :
*mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B
*
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107376#comment-16107376
]
Med Reda commented on MRELEASE-911:
---
When i use release:prepare with release:perform it works fin and it creates a
tag otherwise i need a branch instead of tag with this command i have the same
issue :
mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MRELEASE-911) release plugin forming incorrect git clone command
[
https://issues.apache.org/jira/browse/MRELEASE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107376#comment-16107376
]
Med Reda edited comment on MRELEASE-911 at 7/31/17 2:41 PM:
When i use release:prepare with release:perform it works fin and it creates a
tag otherwise i need a branch instead of tag with this command i have the same
issue :
*mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B
*
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
was (Author: inforedaster):
When i use release:prepare with release:perform it works fin and it creates a
tag otherwise i need a branch instead of tag with this command i have the same
issue :
mvn clean -DreleaseVersion=${v} -DdevelopmentVersion=${newdevversion}
-DpreparationGoals=clean verify release:branch -DbranchName=release-${v}
release:perform
-DconnectionUrl=scm:git:g...@git.project.net:project-domaine/poc/reda-projects.git
-B
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:perform (default-cli) on
project impulse-sdk: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: repository
'/home/jenkins/workspace/release-exp/reda-projects/target/checkout' does not
exist
When i check the existing directory :
'/home/jenkins/workspace/release-exp/reda-projects/target but not have a
"checkout" directory.
any idea ?
> release plugin forming incorrect git clone command
> --
>
> Key: MRELEASE-911
> URL: https://issues.apache.org/jira/browse/MRELEASE-911
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.5.2
>Reporter: sandyzden
>
> git-exe plugin completely ignores the branch parameter and fails in cloning
> the repository during {{release:perform}}
> e.g. git clone --branch this causes it to determine
> the as the branch parameter and failing.
> Below is the error message
> {noformat}
> [ERROR] The git-clone command failed.
> [ERROR] fatal: repository '/target/checkout' does not exist
> {noformat}
> A bit fiddling on the source code i found out
> {code}
> if ( version != null && ( version instanceof ScmBranch ) )
> {
> cl.createArg().setValue( "--branch" );
> cl.createArg().setValue( version.getName() );
> }
> {code}
> it needed version number, but i was not able to figure how it passed from
> Main Mojo to this class
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6262) getCanonicalFile() is not used consistently during project resolution
[
https://issues.apache.org/jira/browse/MNG-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107117#comment-16107117
]
Dawid Weiss commented on MNG-6262:
--
Related issue which compares file URIs and suffers from the same problem.
Also: hard and symlinks on Windows (NTFS) definitely exist (I use them, for
example), so inconsistent canonicalization or comparing by URIs is probably not
a good idea.
> getCanonicalFile() is not used consistently during project resolution
> -
>
> Key: MNG-6262
> URL: https://issues.apache.org/jira/browse/MNG-6262
> Project: Maven
> Issue Type: Bug
> Components: core, Reactor and workspace
>Affects Versions: 3.5.0, 3.5.1-candidate
> Environment: Windows 7
>Reporter: Gene Smith
>Priority: Minor
> Attachments: test-inconsistent-canonicalization.zip
>
>
> This bug manifests with...
> * maven 3.5.0 *AND WITH* maven built from 3.5.1's unreleased sources
> * on Windows 7 when the "Drive Letter" is configured with the wrong case.
> * in projects which descend from a pom which does not reference them.
> On Windows getCanonicalFile() is used on module File objects before they
> are wrapped in a FileSource and cached. But DefaultModelBuilder compares
> its cache hits against a File which has not been made cananonical.
> Normally it does not matter on Windows, because the lack of symbolic links
> makes it difficult to find an "Absolute File" which is not the same as its
> "Canonical File", but there is at least one use case it happens in...
> If invoking scripts use a "lower case drive letter" (ex: c:\, d:\, etc...)
> then the "Canonical File" has an "upper case drive letter".
> The error only seems to occur if a POM references a parent which does not list
> the referencing POM as a child. In other words, when there is POM inheritance
> without a reactor module relationship. In my use case there is a Dependency
> Management POM which does not reference all the modules which list it as their
> parent.
> A simple work around is...
> Make sure all your Windows Environments have capital drive letters in the
> Jenkins node configuration, and scripting.
> ..
> {noformat}
> Testing from sources:
> https://git-wip-us.apache.org/repos/asf/maven.git
> origin/master
> b10025751 (HEAD -> master, origin/master, origin/MNG-5457_2,
> origin/HEAD) [MNG-5457] Show repository id when downloading or uploading
> from/to a remote repository
> https://git-wip-us.apache.org/repos/asf/maven-resolver.git
> origin/master
> c9212232 (HEAD -> master, origin/master, origin/HEAD)
> [maven-release-plugin] prepare for next development iteration
> {noformat}
> I found {{DefaultModelBuilder}} compares a POM's Non-Canonical File's URI
> against a
> cached Model's POM's Canonical File's URI.
> {code}
> org.apache.maven.model.building.DefaultModelBuilder
> File pomFile = parentData.getModel().getPomFile();
> if ( pomFile != null )
> {
> ModelSource expectedParentSource = getParentPomFile( childModel,
> childSource );
> if ( expectedParentSource instanceof ModelSource2
> && !pomFile.toURI().equals( ( (ModelSource2)
> expectedParentSource ).getLocationURI() ) )
> {
> parentData = readParentExternally( childModel, request,
> problems );
> }
> }
> {code}
> Where {{ModelSource2}} is a {{org.apache.maven.building.FileSource}} which
> has been
> made from a canonical file.
> In my test environment it composed and compared these two URIs for
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and found they did not match:
> file:/C:/Jenkins/workspace/test/pom.xml
> file:/c:/Jenkins/workspace/test/pom.xml
> resulting in this error output:
> {noformat}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong local POM @
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT,
> C:\Jenkins\workspace\test\reactor\pom.xml, line 5, column 11
> @
> [ERROR] The build could not read 1 project -> [Help 1]
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [FATAL] Non-resolvable parent POM for
> test-inconsistent-canonicalization:reactor:1.0.0-SNAPSHOT: Could not find
> artifact
> test-inconsistent-canonicalization:dependency-management:pom:1.0.0-SNAPSHOT
> and 'parent.relativePath' points at wrong
[jira] [Commented] (MNG-6266) Getting error " 2.6 or one of its dependencies could not be resolved" while creating a project in Eclipse.
[ https://issues.apache.org/jira/browse/MNG-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107025#comment-16107025 ] Saket Kumar commented on MNG-6266: -- Thanks a lot Robert for the suggestion. > Getting error " 2.6 or one of its dependencies could not be resolved" while > creating a project in Eclipse. > -- > > Key: MNG-6266 > URL: https://issues.apache.org/jira/browse/MNG-6266 > Project: Maven > Issue Type: Task > Environment: Windows 8.1, 64 bit OS >Reporter: Saket Kumar > Attachments: maven_err.png > > > Issue description: > When creating a maven project in Eclipse(version neon.3) getting error "2.6 > or one of its dependencies could not be resolved, Failed to read artifact > descriptor for org.apache.maven.plugins". > Expected: Maven Project should get created. > Actual: Not able to create maven project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MINDEXER-105) README.md points to wrong issue tracker (Codehaus)
Andreas Sewe created MINDEXER-105:
-
Summary: README.md points to wrong issue tracker (Codehaus)
Key: MINDEXER-105
URL: https://issues.apache.org/jira/browse/MINDEXER-105
Project: Maven Indexer
Issue Type: Bug
Reporter: Andreas Sewe
Priority: Trivial
The current {{README.md}}, as rendered at
https://github.com/apache/maven-indexer/, points to the non-existent Codehaus
JIRA. This should be updated to point here instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MPOM-134) Add profile to use a different resource bundle for incubator projects
[
https://issues.apache.org/jira/browse/MPOM-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106878#comment-16106878
]
Hervé Boutemy edited comment on MPOM-134 at 7/31/17 7:00 AM:
-
yes, option 3 is the way to go to add an additional {{resourceBundle}} value
from a profile
the question is: how to activate this profile?
do you expect to add instructions to activate the profile manually through
{{mvn -Pincubator}}?
Notice: I'm struggling with an equivalent issue after MPOM-96: writing the
profile was a first step, but now I see that the big issue is to make is
automagically activate (and the pom property I documented just does not work...)
was (Author: hboutemy):
yes, option 3 is the way to go to add an additional {{resourceBundle}} value
from a profile
the question is: how to activate this profile?
you expect to add instructions to activate the profile manually through {{mvn
-Pincubator}}?
(I'm struggling with an equivalent issue after MPOM-96: writing the profile was
a first step, but now I see that the big issue is to make is automagically
activate (and the pom property I documented just does not work...)
> Add profile to use a different resource bundle for incubator projects
> -
>
> Key: MPOM-134
> URL: https://issues.apache.org/jira/browse/MPOM-134
> Project: Maven POMs
> Issue Type: Improvement
>Affects Versions: ASF-18
>Reporter: Christopher Tubbs
> Fix For: ASF-19
>
>
> The {{org.apache:apache-jar-resource-bundle:1.4}} resourceBundle currently
> specified in the parent POM does not handle the DISCLAIMER file for incubator
> projects.
> It would be nice if there were an incubation profile, which could be
> activated for incubating projects, to use an incubating resource bundle which
> did handle this DISCLAIMER file.
> This could be done in several ways:
> # An optional second execution of the {{maven-remote-resources-plugin}} could
> run when the profile is activated, which handles a second resource bundle for
> the DISCLAIMER file.
> # The current resourceBundle could be turned into a property, which is
> overridden when the profile is activated, using a resourceBundle which
> handles everything the current one does, plus the DISCLAIMER file.
> # The current {{maven-remote-resources-plugin}} execution could have the
> {{}} element changed to {{ combine.children="append">}}, and the profile could specify an additional
> {{}} to handle the DISCLAIMER file, for the same execution id
> of {{maven-remote-resources-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MPOM-134) Add profile to use a different resource bundle for incubator projects
[
https://issues.apache.org/jira/browse/MPOM-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106878#comment-16106878
]
Hervé Boutemy commented on MPOM-134:
yes, option 3 is the way to go to add an additional {{resourceBundle}} value
from a profile
the question is: how to activate this profile?
you expect to add instructions to activate the profile manually through {{mvn
-Pincubator}}?
(I'm struggling with an equivalent issue after MPOM-96: writing the profile was
a first step, but now I see that the big issue is to make is automagically
activate (and the pom property I documented just does not work...)
> Add profile to use a different resource bundle for incubator projects
> -
>
> Key: MPOM-134
> URL: https://issues.apache.org/jira/browse/MPOM-134
> Project: Maven POMs
> Issue Type: Improvement
>Affects Versions: ASF-18
>Reporter: Christopher Tubbs
> Fix For: ASF-19
>
>
> The {{org.apache:apache-jar-resource-bundle:1.4}} resourceBundle currently
> specified in the parent POM does not handle the DISCLAIMER file for incubator
> projects.
> It would be nice if there were an incubation profile, which could be
> activated for incubating projects, to use an incubating resource bundle which
> did handle this DISCLAIMER file.
> This could be done in several ways:
> # An optional second execution of the {{maven-remote-resources-plugin}} could
> run when the profile is activated, which handles a second resource bundle for
> the DISCLAIMER file.
> # The current resourceBundle could be turned into a property, which is
> overridden when the profile is activated, using a resourceBundle which
> handles everything the current one does, plus the DISCLAIMER file.
> # The current {{maven-remote-resources-plugin}} execution could have the
> {{}} element changed to {{ combine.children="append">}}, and the profile could specify an additional
> {{}} to handle the DISCLAIMER file, for the same execution id
> of {{maven-remote-resources-plugin}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MASFRES-18) typo 'teh' on m23 announcement
[ https://issues.apache.org/jira/browse/MASFRES-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106875#comment-16106875 ] Hervé Boutemy commented on MASFRES-18: -- I fixed the title. I don't understand how this is related to apache-incubator-disclaimer-resource-bundle, which is used to generate META-INF/DISCLAIMER how is your announcement generated? > typo 'teh' on m23 announcement > -- > > Key: MASFRES-18 > URL: https://issues.apache.org/jira/browse/MASFRES-18 > Project: Apache Maven Resource Bundles > Issue Type: Improvement > Components: apache-incubator-disclaimer-resource-bundle > Environment: https://directory.apache.org/apacheds/news.html >Reporter: David Misell >Priority: Trivial > > there is a typo on the latest m23 announcement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MASFRES-18) typo 'teh' on m23 announcement
[ https://issues.apache.org/jira/browse/MASFRES-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MASFRES-18: - Summary: typo 'teh' on m23 announcement (was: type 'teh' on m23 announcement) > typo 'teh' on m23 announcement > -- > > Key: MASFRES-18 > URL: https://issues.apache.org/jira/browse/MASFRES-18 > Project: Apache Maven Resource Bundles > Issue Type: Improvement > Components: apache-incubator-disclaimer-resource-bundle > Environment: https://directory.apache.org/apacheds/news.html >Reporter: David Misell >Priority: Trivial > > there is a typo on the latest m23 announcement -- This message was sent by Atlassian JIRA (v6.4.14#64029)
