[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027190#comment-16027190
 ] 

Tibor Digana edited comment on SUREFIRE-1372 at 5/27/17 4:45 AM:
-

[~mpkorstanje]
Ok, lets try to use latest cucumber release version without having 
{{2.0.0-SNAPSHOT}} and run the build of surefire {{mvn install -P run-its}}. Is 
the build successful?
Is there any way of using {{CucumberOptions}} with re-run in the old release 
versions of cucumber?
Any drawback?
Maybe the users of surefire and Cucubmer would prefer some documentation in 
surefire if current {{CucumberOptions}} are possible.


was (Author: tibor17):
[~mpkorstanje]
Ok, lets try to use latest cucumber release version without having 
{{2.0.0-SNAPSHOT}} and run the build of surefire {{mvn install -P run-its}}. Is 
the build successful?
Is there any way using {{CucumberOptions}} in re-run?
Any drawback?
Maybe the users of surefire and Cucubmer would prefer some documentation in 
surefire if current {{CucumberOptions}} are possible.

> 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.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027190#comment-16027190
 ] 

Tibor Digana commented on SUREFIRE-1372:


[~mpkorstanje]
Ok, lets try to use latest cucumber release version without having 
{{2.0.0-SNAPSHOT}} and run the build of surefire {{mvn install -P run-its}}. Is 
the build successful?
Is there any way using {{CucumberOptions}} in re-run?
Any drawback?
Maybe the users of surefire and Cucubmer would prefer some documentation in 
surefire if current {{CucumberOptions}} are possible.

> 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.3.15#6346)

[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread M.P. Korstanje (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026814#comment-16026814
 ] 

M.P. Korstanje edited comment on SUREFIRE-1372 at 5/26/17 8:58 PM:
---

There will be no patch version of {{cucumber-jvm}}.  I'll ask for an e.t.a. on 
the 2.0.0 release but as far as I am concerned there is no need for surefire to 
wait for {{cucumber-jvm:2.0.0}}. I'm not in a rush. 

I've added integration tests and created a PR against maven-surefire: 
https://github.com/apache/maven-surefire/pull/150

However note that this uses {{cucumber-jvm:2.0.0-SNAPSHOT}} and depends on 
features that have yet to be merged. 



was (Author: mpkorstanje):
There will be no patch version of {{cucumber-jvm}}.  I'll ask for an e.t.a. on 
the 2.0.0 release but as far as I am concerned there is no need for surefire to 
wait for {{cucumber-jvm:2.0.0}}. I'm not in a rush. 

I've added integration tests and created a PR against maven-surefire: 
https://github.com/apache/maven-surefire/pull/150

However note that this uses {{cucumber-jvm:2.0.0-SNAPSHOT}}. 


> 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.3.15#6346)

[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread M.P. Korstanje (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026814#comment-16026814
 ] 

M.P. Korstanje edited comment on SUREFIRE-1372 at 5/26/17 8:47 PM:
---

There will be no patch version of {{cucumber-jvm}}.  I'll ask for an e.t.a. on 
the 2.0.0 release but as far as I am concerned there is no need for surefire to 
wait for {{cucumber-jvm:2.0.0}}. I'm not in a rush. 

I've added integration tests and created a PR against maven-surefire: 
https://github.com/apache/maven-surefire/pull/150

However note that this uses {{cucumber-jvm:2.0.0-SNAPSHOT}}. 



was (Author: mpkorstanje):
There will be no patch version of {{cucumber-jvm}}.  I'll ask for an e.t.a. on 
the 2.0.0 release but as far as I am concerned there is no need for surefire to 
wait for {{cucumber-jvm:2.0.0}}. I'm not in a rush. 

I've added integration tests and created a PR against maven-surefire: 
https://github.com/apache/maven-surefire/pull/150

However not that this uses {{cucumber-jvm:2.0.0-SNAPSHOT}}. 


> 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.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread M.P. Korstanje (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026814#comment-16026814
 ] 

M.P. Korstanje commented on SUREFIRE-1372:
--

There will be no patch version of {{cucumber-jvm}}.  I'll ask for an e.t.a. on 
the 2.0.0 release but as far as I am concerned there is no need for surefire to 
wait for {{cucumber-jvm:2.0.0}}. I'm not in a rush. 

I've added integration tests and created a PR against maven-surefire: 
https://github.com/apache/maven-surefire/pull/150

However not that this uses {{cucumber-jvm:2.0.0-SNAPSHOT}}. 


> 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.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026800#comment-16026800
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
This is still WIP until cucumber-jvm 2.0.0 is done.


> 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.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026799#comment-16026799
 ] 

ASF GitHub Bot commented on SUREFIRE-1372:
--

GitHub user mpkorstanje opened a pull request:

https://github.com/apache/maven-surefire/pull/150

SUREFIRE-1372 Filter tests to be rerun by description

 Filtering tests by the tuple of (Class, Method) does not work when a test
 suite is used as a suite may not have (Class, Method) . Filtering by the
 description of the failed test should however work.

 Related Issues:
 - https://github.com/cucumber/cucumber-jvm/issues/1120
 - https://github.com/temyers/cucumber-jvm-parallel-plugin/issues/31

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mpkorstanje/maven-surefire SUREFIRE-1372

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/150.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #150


commit 0ede21cb929df8004f065db82304061e0e0929d5
Author: mpkorstanje 
Date:   2017-05-10T21:59:31Z

SUREFIRE-1372 Filter tests to be rerun by description

 Filtering tests by the tuple of (Class, Method) does not work when a test
 suite is used as a suite may not have (Class, Method) . Filtering by the
 description of the failed test should however work.

 Related Issues:
 - https://github.com/cucumber/cucumber-jvm/issues/1120
 - https://github.com/temyers/cucumber-jvm-parallel-plugin/issues/31




> 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.3.15#6346)

[jira] [Comment Edited] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026770#comment-16026770
 ] 

Tibor Digana edited comment on SUREFIRE-1372 at 5/26/17 8:13 PM:
-

[~mpkorstanje]
Do we really need to wait for {{cucumber-jvm:2.0.0}}?
I knew I lost some ticket from my view. It was this.
I would like to assign this fix to version {{2.20.1}} but we would need to have 
integration test(s); otherwise I may lose it again.
If you are sure {{cucumber-jvm:2.0.0}} is going to be released you can prepare 
IT with {{2.0.0-SNAPSHOT}} version. We would need to have one commit in this 
feature, so you can always amend latest commit which would be the way to follow 
with surefire {{2.20.1}}.


was (Author: tibor17):
[~mpkorstanje]
Do we really need to wait for {{cucumber-jvm:2.0.0}}?
I knew I lost some ticket from my view. It was this.
I would like to assign this fix to version {{2.20.1}} but we would need to have 
integration test(s); otherwise I may lose it again.
If you are sure {{cucumber-jvm:2.0.0}} is going to be released you can prepare 
IT with {{2.2.0-SNAPSHOT}} version. We would need to have one commit in this 
feature, so you can always amend latest commit which would be the way to follow 
with surefire {{2.20.1}}.

> 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.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread Tibor Digana (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026770#comment-16026770
 ] 

Tibor Digana commented on SUREFIRE-1372:


[~mpkorstanje]
Do we really need to wait for {{cucumber-jvm:2.0.0}}?
I knew I lost some ticket from my view. It was this.
I would like to assign this fix to version {{2.20.1}} but we would need to have 
integration test(s); otherwise I may lose it again.
If you are sure {{cucumber-jvm:2.0.0}} is going to be released you can prepare 
IT with {{2.2.0-SNAPSHOT}} version. We would need to have one commit in this 
feature, so you can always amend latest commit which would be the way to follow 
with surefire {{2.20.1}}.

> 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.3.15#6346)

[jira] [Commented] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-26 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026399#comment-16026399
 ] 

Michael Osipov commented on MRESOLVER-25:
-

Does the workaround work for you?

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml

2017-05-26 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026397#comment-16026397
 ] 

Michael Osipov commented on MNG-5984:
-

[~Gohla], do you think you could bundle up a sample project for this? I'd like 
to turn this into an IT.

> 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.1-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.3.15#6346)

[jira] [Updated] (SUREFIRE-1374) std/in stream corrupted error

2017-05-26 Thread matteo rulli (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

matteo rulli updated SUREFIRE-1374:
---
Description: 
We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[
{code}

Everything worked fine with 2.19.1.

Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0  

  was:
We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at

[jira] [Commented] (MASSEMBLY-833) Ability to ignore errors about no files to package in assembly

2017-05-26 Thread Michael Osipov (JIRA) 

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026164#comment-16026164
 ] 

Michael Osipov commented on MASSEMBLY-833:
--

PR has been merged.

> Ability to ignore errors about no files to package in assembly
> --
>
> Key: MASSEMBLY-833
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-833
> Project: Maven Assembly Plugin
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Martin Vehovský
> Attachments: 
> _MASSEMBLY_833__added_ignoreNoFiles_parameter_allowing_not_to_fail_when_there_are_no_files.patch
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Motivation: Having extremely large multi-module project, some modules lets 
> call them "application" modules provide "configuration" files, and they 
> provide them for different environments. Problem is that not all 
> "application" modules provide "configuration" files for all environments. In 
> case there are no files available for assembly, the single goal ends up with 
> ERROR:
> Failed to
>  create assembly: Error creating assembly archive : You must 
> set at least one file.
> Available workaround is to specify a property to by default skip the assembly 
> execution and only if there are files for given environment set this property 
> to not skip the given assembly execution.
> However for large number of environments this solution starts to be messy and 
> hard to maintain.
> Do you think that having assembly Parameter "ignoreNoFiles" that will cause 
> to skip the archive creation for cases there are no files to package seems 
> like reasonable solution?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest

2017-05-26 Thread Mario Toffia (JIRA) 

[ 
https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026077#comment-16026077
 ] 

Mario Toffia commented on MJAR-193:
---

[~khmarbaise] I would also like this functionality. Is it possible to 
incorporate such behavior?

> Allow other mojos to contribute to the manifest
> ---
>
> Key: MJAR-193
> URL: https://issues.apache.org/jira/browse/MJAR-193
> Project: Maven JAR Plugin
>  Issue Type: Improvement
>Reporter: Carsten Ziegeler
> Fix For: waiting-for-feedback
>
>
> It would be great to have a programmatic way to add entries to the manifest 
> from other mojos. The most important client of such a way would be the maven 
> bundle plugin (from the Apache Felix project) that calculates additional 
> headers for OSGi bundles. Right now, that bundle does not only do the 
> calculation but generates the jar file as well.
> While a workaround would be to let the bundle plugin generate the full 
> manifest and configure the jar plugin to use it, this is not very elegant. 
> Passing down a map of manifest entries from one mojo to the jar plugin would 
> solve this in a much better way.
> And I could imagine that other mojos/plugins might benefit for this as well.
> This would be a simple but very convenient enhancement to the plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARCHETYPE-528) Archetype:generate from repos besides central does not work

2017-05-26 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026036#comment-16026036
 ] 

João Cabrita edited comment on ARCHETYPE-528 at 5/26/17 9:12 AM:
-

And, after some more investigation:

Using
{noformat}
-P camunda -X -DgroupId=the.groupId -DartifactId=bpm-stuff 
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.camunda.bpm.archetype 
-DarchetypeArtifactId=camunda-archetype-servlet-war -DarchetypeVersion=7.6.2 
-DarchetypeRepository=https://app.camunda.com/nexus/content/repositories/camunda-bpm/
 org.apache.maven.plugins:maven-archetype-plugin:RELEASE:generate
{noformat}

I get the following output:
{noformat}
[INFO] Generating project in Interactive mode
[DEBUG] Searching for remote catalog: 
https://repo.maven.apache.org/maven2/archetype-catalog.xml
[WARNING] No archetype found in remote catalog. Defaulting to internal catalog
[DEBUG] Using catalog C:\Users\joao.cabrita\.m2\repository\archetype-catalog.xml
[WARNING] Archetype not found in any catalog. Falling back to central 
repository.
[WARNING] Add a repsoitory with id 'archetype' in your settings.xml if 
archetype's repository is elsewhere.
[DEBUG] Not found archetype 
org.camunda.bpm.archetype:camunda-archetype-servlet-war:7.6.2 in cache
[DEBUG] Using transporter WagonTransporter with priority -1.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm via 
proxy.brisa.pt:3128 with username=, password=***
Downloading: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
Downloaded: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
 (2 KB at 2.9 KB/sec)
{noformat}

So it seems to me that some things aren't quite right:
* maven central is hardcoded into the plugin
* the "archetype" repository isn't being used for fetching the catalog but can 
be used for fetching artifacts
* it complains about the "archetype" repository missing despite it being defined


was (Author: kewne):
And, after some more investigation:

Using
{noformat}
-P camunda -X -DgroupId=the.groupId -DartifactId=bpm-stuff 
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.camunda.bpm.archetype 
-DarchetypeArtifactId=camunda-archetype-servlet-war -DarchetypeVersion=7.6.2 
-DarchetypeRepository=https://app.camunda.com/nexus/content/repositories/camunda-bpm/
 org.apache.maven.plugins:maven-archetype-plugin:RELEASE:generate
{noformat}

I get the following output:
{noformat}
[INFO] Generating project in Interactive mode
[DEBUG] Searching for remote catalog: 
https://repo.maven.apache.org/maven2/archetype-catalog.xml
[WARNING] No archetype found in remote catalog. Defaulting to internal catalog
[DEBUG] Using catalog C:\Users\joao.cabrita\.m2\repository\archetype-catalog.xml
[WARNING] Archetype not found in any catalog. Falling back to central 
repository.
[WARNING] Add a repsoitory with id 'archetype' in your settings.xml if 
archetype's repository is elsewhere.
[DEBUG] Not found archetype 
org.camunda.bpm.archetype:camunda-archetype-servlet-war:7.6.2 in cache
[DEBUG] Using transporter WagonTransporter with priority -1.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm via 
proxy.brisa.pt:3128 with username=, password=***
Downloading: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
Downloaded: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
 (2 KB at 2.9 KB/sec)
{noformat}

So it seems to me that some things aren't quite right:
* maven central is hardcoded into the plugin
* the "archetype" repository isn't being used for fetching the catalog but can 
be used for fetching artifacts

> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote  
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate 
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results

[jira] [Commented] (ARCHETYPE-528) Archetype:generate from repos besides central does not work

2017-05-26 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026036#comment-16026036
 ] 

João Cabrita commented on ARCHETYPE-528:


And, after some more investigation:

Using
{noformat}
-P camunda -X -DgroupId=the.groupId -DartifactId=bpm-stuff 
-Dversion=1.0-SNAPSHOT -DarchetypeGroupId=org.camunda.bpm.archetype 
-DarchetypeArtifactId=camunda-archetype-servlet-war -DarchetypeVersion=7.6.2 
-DarchetypeRepository=https://app.camunda.com/nexus/content/repositories/camunda-bpm/
 org.apache.maven.plugins:maven-archetype-plugin:RELEASE:generate
{noformat}

I get the following output:
{noformat}
[INFO] Generating project in Interactive mode
[DEBUG] Searching for remote catalog: 
https://repo.maven.apache.org/maven2/archetype-catalog.xml
[WARNING] No archetype found in remote catalog. Defaulting to internal catalog
[DEBUG] Using catalog C:\Users\joao.cabrita\.m2\repository\archetype-catalog.xml
[WARNING] Archetype not found in any catalog. Falling back to central 
repository.
[WARNING] Add a repsoitory with id 'archetype' in your settings.xml if 
archetype's repository is elsewhere.
[DEBUG] Not found archetype 
org.camunda.bpm.archetype:camunda-archetype-servlet-war:7.6.2 in cache
[DEBUG] Using transporter WagonTransporter with priority -1.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for 
https://app.camunda.com/nexus/content/repositories/camunda-bpm via 
proxy.brisa.pt:3128 with username=, password=***
Downloading: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
Downloaded: 
https://app.camunda.com/nexus/content/repositories/camunda-bpm/org/camunda/bpm/archetype/camunda-archetype-servlet-war/7.6.2/camunda-archetype-servlet-war-7.6.2.pom
 (2 KB at 2.9 KB/sec)
{noformat}

So it seems to me that some things aren't quite right:
* maven central is hardcoded into the plugin
* the "archetype" repository isn't being used for fetching the catalog but can 
be used for fetching artifacts

> Archetype:generate from repos besides central does not work
> ---
>
> Key: ARCHETYPE-528
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-528
> Project: Maven Archetype
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: João Cabrita
>Priority: Critical
> Attachments: settings.xml
>
>
> {noformat}
> mvn -X -P camunda -DarchetypeCatalog=remote  
> org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate 
> -Dfilter=org.camunda.bpm.archetype:
> {noformat}
> Results in the following:
> {noformat}
> [DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate' with basic 
> configurator -->
> [DEBUG]   (f) archetypeCatalog = remote
> [DEBUG]   (f) basedir = C:\Users\joao.cabrita\projects\bpm
> [DEBUG]   (f) filter = org.camunda.bpm.archetype:
> [DEBUG]   (f) interactiveMode = true
> [DEBUG]   (f) localRepository =   id: local
>   url: file:///C:/Users/joao.cabrita/.m2/repository/
>layout: default
> snapshots: [enabled => true, update => always]
>  releases: [enabled => true, update => always]
> [DEBUG]   (f) remoteArtifactRepositories = [  id: central
>   url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
>  releases: [enabled => true, update => daily]
> ,   id: archetype
>   url: https://app.camunda.com/nexus/content/repositories/camunda-bpm
>layout: default
> proxy: proxy.brisa.pt:3128
> snapshots: [enabled => true, update => daily]
>  releases: [enabled => true, update => daily]
> ]
> [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@325f7fa9
> [DEBUG] -- end configuration --
> [INFO] Generating project in Interactive mode
> [DEBUG] Searching for remote catalog: 
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> [WARNING] No archetype found in remote catalog. Defaulting to internal catalog
> [INFO] Your filter doesn't match any archetype, so try again with another 
> value.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {noformat}
> I've attached my settings.xml file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SUREFIRE-1374) std/in stream corrupted error

2017-05-26 Thread matteo rulli (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

matteo rulli updated SUREFIRE-1374:
---
Description: 
We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[
{code}

Everything worked fine with 2.19.1.

  was:
We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)

[jira] [Created] (SUREFIRE-1374) std/in stream corrupted error

2017-05-26 Thread matteo rulli (JIRA) 
matteo rulli created SUREFIRE-1374:
--

 Summary: std/in stream corrupted error
 Key: SUREFIRE-1374
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.20
Reporter: matteo rulli


We bumbed surefire version to 2.20 (from 2.19.1) and our integration tests 
started generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[
{code}

Every worked fine with 2.19.1.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription

2017-05-26 Thread M.P. Korstanje (JIRA) 

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026016#comment-16026016
 ] 

M.P. Korstanje commented on SUREFIRE-1372:
--

Maintainer of cucumber-jvm has been located. Currently waiting for 
[#1134|https://github.com/cucumber/cucumber-jvm/pull/1134] and the release of 
cucumber-jvm 2.0.0.

Still not expecting to make the deadline for 2.20.1.



> 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.3.15#6346)

[jira] [Updated] (SUREFIRE-1374) std/in stream corrupted error

2017-05-26 Thread matteo rulli (JIRA) 

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

matteo rulli updated SUREFIRE-1374:
---
Description: 
We bumbed surefire version to 2.20 (from 2.19.1) and our tests started 
generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
[ERROR] at 
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
[ERROR] at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
[ERROR] at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR] at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
[ERROR] at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[
{code}

Every worked fine with 2.19.1.

  was:
We bumbed surefire version to 2.20 (from 2.19.1) and our integration tests 
started generating this kind of errors:

{code}
# Created on 2017-05-26T10:24:04.032
[SUREFIRE] std/in stream corrupted
java.io.IOException: Command BYE_ACK unexpectedly read Void data with length 4.
at 
org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
at 
org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
at java.lang.Thread.run(Thread.java:745)
{code}

Related stacktrace:

{code}
[ERROR] Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error 
occurred in starting fork, check output in log
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
[ERROR] at 
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
[ERROR] at

[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-26 Thread Roland Illig (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Illig updated MRESOLVER-25:
--
Comment: was deleted

(was: Hello [~michael-o], did you find time to look into this issue?)

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-26 Thread Roland Illig (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Illig updated MRESOLVER-25:
--
Comment: was deleted

(was: Hello [~michael-o], did you find time to look into this issue?)

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (MRESOLVER-25) Resume support is broken under high concurrency

2017-05-26 Thread Roland Illig (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roland Illig updated MRESOLVER-25:
--
Comment: was deleted

(was: Hello [~michael-o]. Is there any progress on this issue?)

> Resume support is broken under high concurrency
> ---
>
> Key: MRESOLVER-25
> URL: https://issues.apache.org/jira/browse/MRESOLVER-25
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.0.3
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip, 
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local 
> Maven repository without taking into account that other threads or processes 
> might do the same at the same time.
> To reproduce:
> 1.  unpack the attached project
> 2.  {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is 
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be 
> found". This is wrong, since the dependency _can_ be found, it's just not 
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since 
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)