[jira] [Commented] (SUREFIRE-1470) Unexpected report result when using rerunFailingTestsCount with groups filter in Surefire

2018-02-02 Thread Alexey Subach (JIRA) 

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

Alexey Subach commented on SUREFIRE-1470:
-

FYI I also filed an issue to TeamCity bug tracker: 
https://youtrack.jetbrains.com/issue/TW-53600
I thing in this case there is a bug in both surefire and TeamCity

> Unexpected report result when using rerunFailingTestsCount with groups filter 
> in Surefire
> -
>
> Key: SUREFIRE-1470
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1470
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Reporter: Alexey Subach
>Priority: Critical
> Attachments: test.zip
>
>
> When the following plugin configuration is used:
> {code:java}
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
> 
> 
> **/*.java
> 
> TestGroup
> 1
> 
> {code}
> And there is a test that fails first time it's run, the resultant *txt* 
> report is unexpected and only contains the result of last rerun.
> Suppose we have the following test class:
> {code:java}
> @Category(TestGroup.class)
> public class CustomTest {
> @Test
> public void alwaysPassingTest() {
> Assert.assertEquals(0, 0);
> }
> private static volatile int x = 0;
> @Test
> public synchronized void secondAttemptPassingTest() throws 
> InterruptedException {
> Thread.sleep(5000);
> if (x++ == 0) {
> Assert.fail();
> }
> }
> }
> {code}
> The resultant xml report is all right, but the txt one is
> {code}
> ---
> Test set: CustomTest
> ---
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 s - in 
> CustomTest
> {code}
> Which is basically incorrect. The *txt* file is regenerated several times 
> during the test run.
> The issue is present when groups filter (either exclusion or inclusion) is 
> present. When there is no group filter and only rerunFailingTestsCount is 
> configured, then the resultant report is the following one:
> {code}
> ---
> Test set: CustomTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.065 s <<< 
> FAILURE! - in CustomTest
> secondAttemptPassingTest(CustomTest)  Time elapsed: 0.009 s  <<< FAILURE!
> java.lang.AssertionError
>   at CustomTest.secondAttemptPassingTest(CustomTest.java:18)
> {code}
> When no group filter is configured, Junit4Provider instead of JunitCore 
> provider is picked up and they seem to handle those cases differently.
> The situation is worsened by the fact that TeamCity is not able to parse the 
> results correctly when the groups are configured along with 
> rerunFailingTestsCount and it marks the tests that passed after rerun as 
> failed, although the overall Maven result is SUCCESS in both cases.
> The simple Maven project to reproduce the issue is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1470) Unexpected report result when using rerunFailingTestsCount with groups filter in Surefire

2018-02-02 Thread Alexey Subach (JIRA) 

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

Alexey Subach updated SUREFIRE-1470:

Attachment: test.zip

> Unexpected report result when using rerunFailingTestsCount with groups filter 
> in Surefire
> -
>
> Key: SUREFIRE-1470
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1470
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Reporter: Alexey Subach
>Priority: Critical
> Attachments: test.zip
>
>
> When the following plugin configuration is used:
> {code:java}
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> ${surefire.version}
> 
> 
> **/*.java
> 
> TestGroup
> 1
> 
> {code}
> And there is a test that fails first time it's run, the resultant *txt* 
> report is unexpected and only contains the result of last rerun.
> Suppose we have the following test class:
> {code:java}
> @Category(TestGroup.class)
> public class CustomTest {
> @Test
> public void alwaysPassingTest() {
> Assert.assertEquals(0, 0);
> }
> private static volatile int x = 0;
> @Test
> public synchronized void secondAttemptPassingTest() throws 
> InterruptedException {
> Thread.sleep(5000);
> if (x++ == 0) {
> Assert.fail();
> }
> }
> }
> {code}
> The resultant xml report is all right, but the txt one is
> {code}
> ---
> Test set: CustomTest
> ---
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 s - in 
> CustomTest
> {code}
> Which is basically incorrect. The *txt* file is regenerated several times 
> during the test run.
> The issue is present when groups filter (either exclusion or inclusion) is 
> present. When there is no group filter and only rerunFailingTestsCount is 
> configured, then the resultant report is the following one:
> {code}
> ---
> Test set: CustomTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.065 s <<< 
> FAILURE! - in CustomTest
> secondAttemptPassingTest(CustomTest)  Time elapsed: 0.009 s  <<< FAILURE!
> java.lang.AssertionError
>   at CustomTest.secondAttemptPassingTest(CustomTest.java:18)
> {code}
> When no group filter is configured, Junit4Provider instead of JunitCore 
> provider is picked up and they seem to handle those cases differently.
> The situation is worsened by the fact that TeamCity is not able to parse the 
> results correctly when the groups are configured along with 
> rerunFailingTestsCount and it marks the tests that passed after rerun as 
> failed, although the overall Maven result is SUCCESS in both cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1470) Unexpected report result when using rerunFailingTestsCount with groups filter in Surefire

2018-02-02 Thread Alexey Subach (JIRA) 

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

Alexey Subach updated SUREFIRE-1470:

Description: 
When the following plugin configuration is used:
{code:java}

org.apache.maven.plugins
maven-surefire-plugin
${surefire.version}


**/*.java

TestGroup
1

{code}


And there is a test that fails first time it's run, the resultant *txt* report 
is unexpected and only contains the result of last rerun.

Suppose we have the following test class:

{code:java}
@Category(TestGroup.class)
public class CustomTest {

@Test
public void alwaysPassingTest() {
Assert.assertEquals(0, 0);
}

private static volatile int x = 0;

@Test
public synchronized void secondAttemptPassingTest() throws 
InterruptedException {
Thread.sleep(5000);
if (x++ == 0) {
Assert.fail();
}
}

}
{code}

The resultant xml report is all right, but the txt one is

{code}
---
Test set: CustomTest
---
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 s - in 
CustomTest
{code}

Which is basically incorrect. The *txt* file is regenerated several times 
during the test run.

The issue is present when groups filter (either exclusion or inclusion) is 
present. When there is no group filter and only rerunFailingTestsCount is 
configured, then the resultant report is the following one:

{code}
---
Test set: CustomTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.065 s <<< 
FAILURE! - in CustomTest
secondAttemptPassingTest(CustomTest)  Time elapsed: 0.009 s  <<< FAILURE!
java.lang.AssertionError
at CustomTest.secondAttemptPassingTest(CustomTest.java:18)
{code}

When no group filter is configured, Junit4Provider instead of JunitCore 
provider is picked up and they seem to handle those cases differently.

The situation is worsened by the fact that TeamCity is not able to parse the 
results correctly when the groups are configured along with 
rerunFailingTestsCount and it marks the tests that passed after rerun as 
failed, although the overall Maven result is SUCCESS in both cases.

The simple Maven project to reproduce the issue is attached.

  was:
When the following plugin configuration is used:
{code:java}

org.apache.maven.plugins
maven-surefire-plugin
${surefire.version}


**/*.java

TestGroup
1

{code}


And there is a test that fails first time it's run, the resultant *txt* report 
is unexpected and only contains the result of last rerun.

Suppose we have the following test class:

{code:java}
@Category(TestGroup.class)
public class CustomTest {

@Test
public void alwaysPassingTest() {
Assert.assertEquals(0, 0);
}

private static volatile int x = 0;

@Test
public synchronized void secondAttemptPassingTest() throws 
InterruptedException {
Thread.sleep(5000);
if (x++ == 0) {
Assert.fail();
}
}

}
{code}

The resultant xml report is all right, but the txt one is

{code}
---
Test set: CustomTest
---
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 s - in 
CustomTest
{code}

Which is basically incorrect. The *txt* file is regenerated several times 
during the test run.

The issue is present when groups filter (either exclusion or inclusion) is 
present. When there is no group filter and only rerunFailingTestsCount is 
configured, then the resultant report is the following one:

{code}
---
Test set: CustomTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.065 s <<< 
FAILURE! - in CustomTest
secondAttemptPassingTest(CustomTest)  Time elapsed: 0.009 s  <<< FAILURE!
java.lang.AssertionError
at CustomTest.secondAttemptPassingTest(CustomTest.java:18)
{code}

When no group filter is configured, Junit4Provider instead of JunitCore 
provider is picked up and they seem to handle those cases differently.

The situation is worsened by the fact that TeamCity is not able to parse the 
results correctly when the groups are configured along with 
rerunFailingTestsCount and it marks the tests that passed after rerun as 
failed, although the overall Maven result is SUCCESS in both cases.

[jira] [Created] (SUREFIRE-1470) Unexpected report result when using rerunFailingTestsCount with groups filter in Surefire

2018-02-02 Thread Alexey Subach (JIRA) 
Alexey Subach created SUREFIRE-1470:
---

 Summary: Unexpected report result when using 
rerunFailingTestsCount with groups filter in Surefire
 Key: SUREFIRE-1470
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1470
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Reporter: Alexey Subach


When the following plugin configuration is used:
{code:java}

org.apache.maven.plugins
maven-surefire-plugin
${surefire.version}


**/*.java

TestGroup
1

{code}


And there is a test that fails first time it's run, the resultant *txt* report 
is unexpected and only contains the result of last rerun.

Suppose we have the following test class:

{code:java}
@Category(TestGroup.class)
public class CustomTest {

@Test
public void alwaysPassingTest() {
Assert.assertEquals(0, 0);
}

private static volatile int x = 0;

@Test
public synchronized void secondAttemptPassingTest() throws 
InterruptedException {
Thread.sleep(5000);
if (x++ == 0) {
Assert.fail();
}
}

}
{code}

The resultant xml report is all right, but the txt one is

{code}
---
Test set: CustomTest
---
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 s - in 
CustomTest
{code}

Which is basically incorrect. The *txt* file is regenerated several times 
during the test run.

The issue is present when groups filter (either exclusion or inclusion) is 
present. When there is no group filter and only rerunFailingTestsCount is 
configured, then the resultant report is the following one:

{code}
---
Test set: CustomTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.065 s <<< 
FAILURE! - in CustomTest
secondAttemptPassingTest(CustomTest)  Time elapsed: 0.009 s  <<< FAILURE!
java.lang.AssertionError
at CustomTest.secondAttemptPassingTest(CustomTest.java:18)
{code}

When no group filter is configured, Junit4Provider instead of JunitCore 
provider is picked up and they seem to handle those cases differently.

The situation is worsened by the fact that TeamCity is not able to parse the 
results correctly when the groups are configured along with 
rerunFailingTestsCount and it marks the tests that passed after rerun as 
failed, although the overall Maven result is SUCCESS in both cases.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on MASSEMBLY-675:
--

hbfernandes opened a new pull request #2: [MASSEMBLY-675] Require maven to 
solve dependencies instead of buildi…
URL: https://github.com/apache/maven-assembly-plugin/pull/2
 
 
   This seems to fix the wildcard exclusion issue, however there might be side 
effects i'm not aware of. My knowledge of maven plugins isn't that extensive so 
any feedback would be appreciated.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Maven Assembly packaging wildcard-excluded dependencies
> ---
>
> Key: MASSEMBLY-675
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-675
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Frank Wilson
>Priority: Major
> Attachments: massembly-675.zip
>
>
> Version 2.4 ignores wildcard exclusions in POM dependencies
> Example (perhaps contrived - but easy to setup):
> When a pom declares a dependency such as closure-compiler and for some reason 
> we do not want to pull its dependencies in we could declare this in our POM, 
> without having to know what those dependencies are:
>   
> 
>   com.google.javascript
>   closure-compiler
>   v20131014
>   
> 
>   *
>   *
> 
>   
> 
>   
> This is a valid use of the exclusion feature as per [Maven 
> Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies],
>  [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about 
> wildcards were 
> [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5]
>  in Git about 10 days ago  
> Here is the assembly descriptor:
> 
>   bin
>   
> dir
>   
>   false
>   
> 
>   
> 
> We expect to only find the current project artifact and the closure-compiler 
> JAR in our directory assembly. However the assembly plugin ignores our POM 
> directive and includes the closure-compilers dependencies anyway!
> Steps to reproduce are:
> $ unzip massembly-675.zip
> $ cd massembly-675
> $ mvn clean install
> $ ls target/massembly-675-1-bin
> args4j-2.0.16.jar  json-20090211.jar  
> protobuf-java-2.4.1.jar
> closure-compiler-v20131014.jar jsr305-1.3.9.jar
> guava-15.0.jar massembly-675-1.jar
> *Notice that the excluded jars are included in the assembly*
> I would expect to only see the following JARs.
> * closure-compiler-v20131014.jar
> * massembly-675-1.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] hbfernandes opened a new pull request #2: [MASSEMBLY-675] Require maven to solve dependencies instead of buildi?

2018-02-02 Thread GitBox 
hbfernandes opened a new pull request #2: [MASSEMBLY-675] Require maven to 
solve dependencies instead of buildi?
URL: https://github.com/apache/maven-assembly-plugin/pull/2
 
 
   This seems to fix the wildcard exclusion issue, however there might be side 
effects i'm not aware of. My knowledge of maven plugins isn't that extensive so 
any feedback would be appreciated.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Deleted] (SUREFIRE-1417) In JIRA, what is the difference between issues and tasks? What's the best way to handle issues vs tasks?

2018-02-02 Thread Chris Lambertus (JIRA) 

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

Chris Lambertus deleted SUREFIRE-1417:
--


> In JIRA, what is the difference between issues and tasks? What's the best way 
> to handle issues vs tasks?
> 
>
> Key: SUREFIRE-1417
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1417
> Project: Maven Surefire
>  Issue Type: Bug
> Environment: windows
>Reporter: nicole wells
>Assignee: Tibor Digana
>Priority: Major
>  Labels: windows
>
> The configurable nature of JIRA means that you can define an Issue Type 
> according to your business needs - it's a customisable, generic element with 
> a handful of useful Attributes that can also be building with additional 
> Custom Fields. You can then extend it further by creating customised 
> workflows to associate to the IssueType, but it does help to have a basic 
> handle on what JIRA does out of the box.
> Issues are what JIRA started with, as a flexible Issues manager in its early 
> days. Tasks are simply a variation of the IssueType. There is also some 
> simple two level hierarchy within vanilla [JIRA Tutorial 
> PDF](https://mindmajix.com/jira-training) that can see a Task decomposed into 
> a number of discrete Sub-Tasks - that hierarchy becomes useful when doing 
> things like capturing time at the Subtask level that you want to see rolled 
> up to the parent Task. 
> I've built + deployed a range of customised JIRA instances where those 
> initial base IssueTypes have been modified for a range of business scenarios 
> to make it a useful Business Process Management platform, with the support of 
> custom workflows and screens - there's a lot you can achieve with it, but I'd 
> start by taking a deeper look at the following resources:
> What is an Issue
> Configuring Workflow



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] slachiewicz opened a new pull request #1: Update site.xml namespace to 1.8.0

2018-02-02 Thread GitBox 
slachiewicz opened a new pull request #1: Update site.xml namespace to 1.8.0
URL: https://github.com/apache/maven-parent/pull/1
 
 
   Align with ASF 19


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user hemachandraraok commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Sure and let me wait!
Thank you so much for the updates!!!Cheers!


> 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
>Priority: Major
> Fix For: 2.21.0.Jigsaw
>
>
> 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
(v7.6.3#76005)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

2018-02-02 Thread hemachandraraok 
Github user hemachandraraok commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Sure and let me wait!
Thank you so much for the updates!!!Cheers!


---

[jira] [Created] (MSHARED-680) Add null check for DependencyResolver Interface

2018-02-02 Thread Karl Heinz Marbaise (JIRA) 
Karl Heinz Marbaise created MSHARED-680:
---

 Summary: Add null check for DependencyResolver Interface
 Key: MSHARED-680
 URL: https://issues.apache.org/jira/browse/MSHARED-680
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-artifact-transfer
Affects Versions: maven-artifact-transfer-1.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
In that case yes, you only need to wait for the release of surefire. 
https://github.com/cucumber/cucumber-jvm/issues/1120 was fixed by 
https://github.com/cucumber/cucumber-jvm/pull/1134 and is part of cucumber-jvm 
2.x.x.


> 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
>Priority: Major
> Fix For: 2.21.0.Jigsaw
>
>
> 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
(v7.6.3#76005)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

2018-02-02 Thread mpkorstanje 
Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
In that case yes, you only need to wait for the release of surefire. 
https://github.com/cucumber/cucumber-jvm/issues/1120 was fixed by 
https://github.com/cucumber/cucumber-jvm/pull/1134 and is part of cucumber-jvm 
2.x.x.


---

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

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user hemachandraraok commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Sorry for not giving enough information. the full track trace is here

org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
testclass 'rerun_test'
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:387)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:293)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
Caused by: java.lang.ClassNotFoundException: rerun_test
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:381)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:293)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)

where 'rerun_test' is the feature file name.

And the cucumber libraries used are 2.3.1 from group Id "io.cucumber"




> 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
>Priority: Major
> Fix For: 2.21.0.Jigsaw
>
>
> 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
(v7.6.3#76005)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

2018-02-02 Thread hemachandraraok 
Github user hemachandraraok commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Sorry for not giving enough information. the full track trace is here

org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
testclass 'rerun_test'
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:387)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:293)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
Caused by: java.lang.ClassNotFoundException: rerun_test
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:381)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:293)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)

where 'rerun_test' is the feature file name.

And the cucumber libraries used are 2.3.1 from group Id "io.cucumber"




---

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

2018-02-02 Thread mpkorstanje 
Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Bit hard to say without the full stack trace, components and version 
numbers involved. 

To fix this bug I also had to fix cucumber to ensure that the it provided 
the proper ids to 
[Description.createSuiteDescription](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L57).
 The ids had to be unique in a single run but when a suite was recreated they 
had to be the same such as to satisfy the equals and hashcode method.


---

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

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
Bit hard to say without the full stack trace, components and version 
numbers involved. 

To fix this bug I also had to fix cucumber to ensure that the it provided 
the proper ids to 
[Description.createSuiteDescription](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L57).
 The ids had to be unique in a single run but when a suite was recreated they 
had to be the same such as to satisfy the equals and hashcode method.


> 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
>Priority: Major
> Fix For: 2.21.0.Jigsaw
>
>
> 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
(v7.6.3#76005)

[jira] [Commented] (MRELEASE-996) Staging a release cleans up

2018-02-02 Thread Ben Maes (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRELEASE-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350280#comment-16350280
 ] 

Ben Maes commented on MRELEASE-996:
---

Implementation seems the correct way for me, else the only difference between 
staging and releasing is the use of a staging repository.

> Staging a release cleans up
> ---
>
> Key: MRELEASE-996
> URL: https://issues.apache.org/jira/browse/MRELEASE-996
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: stage
>Affects Versions: 2.5.3
>Reporter: Ben Maes
>Priority: Major
>
> The wiki's documentation says the following about staging a release:
> {quote}
> After the release is complete, the release.properties and other release files 
> will NOT be removed, so that you can still execute a release:rollback if some 
> error has been detected and a new candidate must be created after some fixes. 
> You just need to use a distinct tag in SCM, or rename the one that has been 
> created if the SCM provider supports renaming tags.
> {quote}
> Found in 
> [usage|http://maven.apache.org/maven-release/maven-release-plugin/usage.html] 
> on the bottom under staging a release
> However everytime I use mvn release:stage the last thing showing up on my 
> commandline is
> {quote}
> [INFO] Uploaded: 
> http://devserver:8081/nexus/content/repositories/release_candidates/be/pensionarchitects/aatest/1.3.8/aatest-1.3.8-javadoc.jar
>  (66 KB at 420.2 KB/sec)
> [INFO] [INFO] 
> 
> [INFO] [INFO] BUILD SUCCESS
> [INFO] [INFO] 
> 
> [INFO] [INFO] Total time: 7.225 s
> [INFO] [INFO] Finished at: 2018-01-31T14:15:21+01:00
> [INFO] [INFO] Final Memory: 25M/310M
> [INFO] [INFO] 
> 
> [INFO] Cleaning up after release...
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 11.333 s
> [INFO] Finished at: 2018-01-31T14:15:21+01:00
> [INFO] Final Memory: 17M/310M
> [INFO] 
> 
> {quote}
> Thx



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

2018-02-02 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user hemachandraraok commented on the issue:

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

Thanks for helping us by contributing to the open source community...

I am using surefire 2.20.1 and getting the same exception 
"org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
test Class".

Could you please let me know if I should be waiting for the next version of 
surefire or am I missing something else here?



> 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
>Priority: Major
> Fix For: 2.21.0.Jigsaw
>
>
> 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
(v7.6.3#76005)

[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...

2018-02-02 Thread hemachandraraok 
Github user hemachandraraok commented on the issue:

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

Thanks for helping us by contributing to the open source community...

I am using surefire 2.20.1 and getting the same exception 
"org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
test Class".

Could you please let me know if I should be waiting for the next version of 
surefire or am I missing something else here?



---

[jira] [Commented] (MRELEASE-996) Staging a release cleans up

2018-02-02 Thread Robert Scholte (JIRA) 

[ 
https://issues.apache.org/jira/browse/MRELEASE-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350214#comment-16350214
 ] 

Robert Scholte commented on MRELEASE-996:
-

Thanks. Now the next question is: what is the fix: implementation or 
documentation? My guess is implementation.

> Staging a release cleans up
> ---
>
> Key: MRELEASE-996
> URL: https://issues.apache.org/jira/browse/MRELEASE-996
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: stage
>Affects Versions: 2.5.3
>Reporter: Ben Maes
>Priority: Major
>
> The wiki's documentation says the following about staging a release:
> {quote}
> After the release is complete, the release.properties and other release files 
> will NOT be removed, so that you can still execute a release:rollback if some 
> error has been detected and a new candidate must be created after some fixes. 
> You just need to use a distinct tag in SCM, or rename the one that has been 
> created if the SCM provider supports renaming tags.
> {quote}
> Found in 
> [usage|http://maven.apache.org/maven-release/maven-release-plugin/usage.html] 
> on the bottom under staging a release
> However everytime I use mvn release:stage the last thing showing up on my 
> commandline is
> {quote}
> [INFO] Uploaded: 
> http://devserver:8081/nexus/content/repositories/release_candidates/be/pensionarchitects/aatest/1.3.8/aatest-1.3.8-javadoc.jar
>  (66 KB at 420.2 KB/sec)
> [INFO] [INFO] 
> 
> [INFO] [INFO] BUILD SUCCESS
> [INFO] [INFO] 
> 
> [INFO] [INFO] Total time: 7.225 s
> [INFO] [INFO] Finished at: 2018-01-31T14:15:21+01:00
> [INFO] [INFO] Final Memory: 25M/310M
> [INFO] [INFO] 
> 
> [INFO] Cleaning up after release...
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 11.333 s
> [INFO] Finished at: 2018-01-31T14:15:21+01:00
> [INFO] Final Memory: 17M/310M
> [INFO] 
> 
> {quote}
> Thx



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MANTTASKS-254) org.apache.tools.ant.taskdefs.ExecuteJava$run method should throw BuildException

2018-02-02 Thread Robert Scholte (JIRA) 

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

Robert Scholte closed MANTTASKS-254.

Resolution: Won't Fix
  Assignee: Robert Scholte

This is a retired project, issue won't be fixed.

> org.apache.tools.ant.taskdefs.ExecuteJava$run method should throw 
> BuildException
> 
>
> Key: MANTTASKS-254
> URL: https://issues.apache.org/jira/browse/MANTTASKS-254
> Project: Maven Ant Tasks (RETIRED)
>  Issue Type: Bug
>  Components: deploy task
>Affects Versions: 2.0.2
> Environment: JDK 1.8
> ANT 2.0.2
>Reporter: Martin Gainty
>Assignee: Robert Scholte
>Priority: Major
> Attachments: ExecuteJava.java
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> {code}
> /**
>  * Execute the Java class against the specified Ant Project.
>  * @param project the Project to use.
>  * @throws BuildException on error.
>  */
> public void execute(Project project) throws BuildException {
> final String classname = javaCommand.getExecutable();
> AntClassLoader loader = null;
> try {
> if (sysProperties != null) {
> sysProperties.setSystem();
> }
> Class target = null;
> try {
> if (classpath == null) {
> target = Class.forName(classname);
> } else {
> loader = project.createClassLoader(classpath);
> loader.setParent(project.getCoreLoader());
> loader.setParentFirst(false);
> loader.addJavaLibraries();
> loader.setIsolated(true);
> loader.setThreadContextLoader();
> loader.forceLoadClass(classname);
> target = Class.forName(classname, true, loader);
> }
> } catch (ClassNotFoundException e) {
> throw new BuildException("Could not find " + classname + "."
>  + " Make sure you have it in your"
>  + " classpath");
> }
> main = target.getMethod("main", new Class[] {String[].class});
> if (main == null) {
> throw new BuildException("Could not find main() method in "
>  + classname);
> }
> if ((main.getModifiers() & Modifier.STATIC) == 0) {
> throw new BuildException("main() method in " + classname
> + " is not declared static");
> }
> if (timeout == null) {
> run();
> } else {
> thread = new Thread(this, "ExecuteJava");
> Task currentThreadTask
> = project.getThreadTask(Thread.currentThread());
> // XXX is the following really necessary? it is in the same 
> thread group...
> project.registerThreadTask(thread, currentThreadTask);
> // if we run into a timeout, the run-away thread shall not
> // make the VM run forever - if no timeout occurs, Ant's
> // main thread will still be there to let the new thread
> // finish
> thread.setDaemon(true);
> Watchdog w = new Watchdog(timeout.longValue());
> w.addTimeoutObserver(this);
> synchronized (this) {
> thread.start();
> w.start();
> try {
> wait();
> } catch (InterruptedException e) {
> // ignore
> }
> if (timedOut) {
> project.log("Timeout: sub-process interrupted",
> Project.MSG_WARN);
> } else {
> thread = null;
> w.stop();
> }
> }
> }
> if (caught != null) {
> throw caught;
> }
> } catch (BuildException e) {
> throw e;
> } catch (SecurityException e) {
> throw e;
> } catch (ThreadDeath e) {
> // XXX could perhaps also call thread.stop(); not sure if anyone 
> cares
> throw e;
> } catch (Throwable e) {
> throw new BuildException(e);
> } finally {
> if (loader != null) {
> loader.resetThreadContextLoader();
> loader.cleanup();
> loader = null;
> }
> if

[jira] [Updated] (MANTTASKS-254) org.apache.tools.ant.taskdefs.ExecuteJava$run method should throw BuildException

2018-02-02 Thread Robert Scholte (JIRA) 

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

Robert Scholte updated MANTTASKS-254:
-
Description: 
{code}
/**
 * Execute the Java class against the specified Ant Project.
 * @param project the Project to use.
 * @throws BuildException on error.
 */
public void execute(Project project) throws BuildException {
final String classname = javaCommand.getExecutable();

AntClassLoader loader = null;
try {
if (sysProperties != null) {
sysProperties.setSystem();
}
Class target = null;
try {
if (classpath == null) {
target = Class.forName(classname);
} else {
loader = project.createClassLoader(classpath);
loader.setParent(project.getCoreLoader());
loader.setParentFirst(false);
loader.addJavaLibraries();
loader.setIsolated(true);
loader.setThreadContextLoader();
loader.forceLoadClass(classname);
target = Class.forName(classname, true, loader);
}
} catch (ClassNotFoundException e) {
throw new BuildException("Could not find " + classname + "."
 + " Make sure you have it in your"
 + " classpath");
}
main = target.getMethod("main", new Class[] {String[].class});
if (main == null) {
throw new BuildException("Could not find main() method in "
 + classname);
}
if ((main.getModifiers() & Modifier.STATIC) == 0) {
throw new BuildException("main() method in " + classname
+ " is not declared static");
}
if (timeout == null) {
run();
} else {
thread = new Thread(this, "ExecuteJava");
Task currentThreadTask
= project.getThreadTask(Thread.currentThread());
// XXX is the following really necessary? it is in the same 
thread group...
project.registerThreadTask(thread, currentThreadTask);
// if we run into a timeout, the run-away thread shall not
// make the VM run forever - if no timeout occurs, Ant's
// main thread will still be there to let the new thread
// finish
thread.setDaemon(true);
Watchdog w = new Watchdog(timeout.longValue());
w.addTimeoutObserver(this);
synchronized (this) {
thread.start();
w.start();
try {
wait();
} catch (InterruptedException e) {
// ignore
}
if (timedOut) {
project.log("Timeout: sub-process interrupted",
Project.MSG_WARN);
} else {
thread = null;
w.stop();
}
}
}
if (caught != null) {
throw caught;
}
} catch (BuildException e) {
throw e;
} catch (SecurityException e) {
throw e;
} catch (ThreadDeath e) {
// XXX could perhaps also call thread.stop(); not sure if anyone 
cares
throw e;
} catch (Throwable e) {
throw new BuildException(e);
} finally {
if (loader != null) {
loader.resetThreadContextLoader();
loader.cleanup();
loader = null;
}
if (sysProperties != null) {
sysProperties.restoreSystem();
}
}
}

/**
 * Run this ExecuteJava in a Thread.
 * @since Ant 1.5
 * TODO: run() should throw BuildException for any compile error
 */
public void run() {
final Object[] argument = {javaCommand.getArguments()};
try {
if (perm != null) {
perm.setSecurityManager();
}
main.invoke(null, argument);
} catch (InvocationTargetException e) {
Throwable t = e.getTargetException();
if (!(t instanceof InterruptedException)) {
caught = t;
} /* else { swallow, probably due to timeout } */
} catch (Throwable t) {
caught = t;
} finally {
if (perm != null) {
perm.restoreSecurityManager();
}
synchronized (this) {

[jira] [Closed] (MDEPLOY-229) Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer in Maven 3.3.9

2018-02-02 Thread Robert Scholte (JIRA) 

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

Robert Scholte closed MDEPLOY-229.
--
Resolution: Invalid
  Assignee: Robert Scholte

> Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer 
> in Maven 3.3.9
> --
>
> Key: MDEPLOY-229
> URL: https://issues.apache.org/jira/browse/MDEPLOY-229
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Maven 3.3.9
>Reporter: Jakub Bochenski
>Assignee: Robert Scholte
>Priority: Critical
>
> The stacktrace is huge but I think the gist is:
> {code:java}
> java.lang.IllegalArgumentException: Can not set 
> org.eclipse.aether.spi.log.Logger field 
> org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger to 
> org.eclipse.aether.internal.impl.slf4j.Slf4jLoggerFactory{code}
> Tried the same with Maven 3.5.0 and it works fine.
> Full stack trace: 
> https://gist.github.com/jakub-bochenski/08b7e9dce1823ef55c2335eb7e79fb14



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MDEPLOY-229) Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer in Maven 3.3.9

2018-02-02 Thread Jakub Bochenski (JIRA) 

[ 
https://issues.apache.org/jira/browse/MDEPLOY-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350190#comment-16350190
 ] 

Jakub Bochenski commented on MDEPLOY-229:
-

This is actually 
https://github.com/HubSpot/dependency-management-maven-plugin/issues/13 but I 
can't close the issue for some reason

> Error injecting: org.apache.maven.artifact.deployer.DefaultArtifactDeployer 
> in Maven 3.3.9
> --
>
> Key: MDEPLOY-229
> URL: https://issues.apache.org/jira/browse/MDEPLOY-229
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Maven 3.3.9
>Reporter: Jakub Bochenski
>Priority: Critical
>
> The stacktrace is huge but I think the gist is:
> {code:java}
> java.lang.IllegalArgumentException: Can not set 
> org.eclipse.aether.spi.log.Logger field 
> org.apache.maven.repository.internal.DefaultVersionRangeResolver.logger to 
> org.eclipse.aether.internal.impl.slf4j.Slf4jLoggerFactory{code}
> Tried the same with Maven 3.5.0 and it works fine.
> Full stack trace: 
> https://gist.github.com/jakub-bochenski/08b7e9dce1823ef55c2335eb7e79fb14



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MNG-6256) Maven script can break if "-f" path contains special characters

2018-02-02 Thread Christoph Etzel (JIRA) 

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

Christoph Etzel edited comment on MNG-6256 at 2/2/18 10:29 AM:
---

[~khmarbaise] can you provide a link to the 3.5.3-candidate, so i can test it? 
I have not found a tag or branch in the git repo. Thanks in advance.


was (Author: etzelc):
[~khmarbaise] can you provide a link to the 3.5.3-candidate, so i can test it? 
I have not found a tag or branch in the git repo.

> Maven script can break if "-f" path contains special characters 
> 
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
>Priority: Major
> Fix For: 3.5.3-candidate
>
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to 
> specify an alternate POM file can break the script if the path contains 
> special characters. 
> It was originally discovered on a Windows Jenkins instance with working 
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle 
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file  '}} and a new calculator process
> The bug was introduced with commit 
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
>  for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}} 
> commands in {{maven.cmd}} (line 120 and 129).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6256) Maven script can break if "-f" path contains special characters

2018-02-02 Thread Christoph Etzel (JIRA) 

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

Christoph Etzel commented on MNG-6256:
--

[~khmarbaise] can you provide a link to the 3.5.3-candidate, so i can test it? 
I have not found a tag or branch in the git repo.

> Maven script can break if "-f" path contains special characters 
> 
>
> Key: MNG-6256
> URL: https://issues.apache.org/jira/browse/MNG-6256
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 10 with PowerShell
>Reporter: Christoph Etzel
>Priority: Major
> Fix For: 3.5.3-candidate
>
>
> Executing maven on Windows using the {{\-f}} or {{--file}} parameter to 
> specify an alternate POM file can break the script if the path contains 
> special characters. 
> It was originally discovered on a Windows Jenkins instance with working 
> directory located under C:\Program Files (x86)\Jenkins..
> Example:
> {code:java}mvn -f "folderWithClosing)Bracket/pomFolder"{code}
> Command line output: {{"Bracket/pomFolder" kann syntaktisch an dieser Stelle 
> nicht verarbeitet werden.}}
> Just for fun: Starting calc from maven script using {{\-f}}
> {code:java}mvn -f " ' & start calc"{code}
> Command line output: {{POM file  '}} and a new calculator process
> The bug was introduced with commit 
> https://github.com/apache/maven/commit/f8ab2a650f32d5d87126d341d9bbfccbf99fd0ca
>  for issue MNG-5889.
> Workaround: Use maven 3.3.9 or below
> Possible fix: Escape {{%FILE_ARG%}} and {{%POM_DIR%}} with {{"}} in {{echo}} 
> commands in {{maven.cmd}} (line 120 and 129).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-02-02 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350014#comment-16350014
 ] 

ASF GitHub Bot commented on MPLUGIN-328:


dheid closed pull request #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188
URL: https://github.com/apache/maven-plugin-tools/pull/11
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
 
b/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
index f4c83010..8b2a15f4 100644
--- 
a/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
+++ 
b/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
@@ -142,7 +142,14 @@ protected void scan( Map 
mojoAnnotatedClasses, File
 {
 continue;
 }
-analyzeClassStream( mojoAnnotatedClasses, archiveStream, 
artifact, excludeMojo );
+try
+{
+analyzeClassStream( mojoAnnotatedClasses, archiveStream, 
artifact, excludeMojo );
+}
+catch ( ArrayIndexOutOfBoundsException e )
+{
+getLogger().warn( "Error analyzing class " + zipEntryName 
);
+}
 }
 }
 catch ( IllegalArgumentException e )


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.5.1
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at

[jira] [Commented] (MPLUGIN-328) ArrayIndexOutOfBoundsException: 48188

2018-02-02 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MPLUGIN-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350013#comment-16350013
 ] 

ASF GitHub Bot commented on MPLUGIN-328:


dheid commented on issue #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188
URL: https://github.com/apache/maven-plugin-tools/pull/11#issuecomment-362528887
 
 
   Maintainer fixed it on his own.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> ArrayIndexOutOfBoundsException: 48188 
> --
>
> Key: MPLUGIN-328
> URL: https://issues.apache.org/jira/browse/MPLUGIN-328
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Affects Versions: 3.5
> Environment: 
> :\Users\fandre\Documents\MXW\MI\MI-4.1.1\Installer>C:\ASF\apache-maven-3.5.0\bin\mvn
>  -version
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 
> 2017-04-03T21:39:06+02:00)
> Maven home: C:\ASF\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_141\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: zosrothko
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.5.1
>
> Attachments: MPLUGIN_328_ArrayIndexOutOfBoundsException__48188.patch, 
> plugin.rar, plugin.zip, pom.xml
>
>
> Hi
> Got a ArrayIndexOutOfBoundsException on the maven-plugin-plugin:3.5 with an 
> empty execution element
> {code:xml}
>   
> maven-plugin-plugin
> 3.5
>   
> {code}
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188 -> 
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor 
> (default-descriptor) on project scortes-maven-plugin: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-descriptor of goal 
> org.apache.maven.plugins:maven-plugin-plugin:3.5:descriptor failed: 48188
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by:

[GitHub] dheid closed pull request #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188

2018-02-02 Thread GitBox 
dheid closed pull request #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188
URL: https://github.com/apache/maven-plugin-tools/pull/11
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
 
b/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
index f4c83010..8b2a15f4 100644
--- 
a/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
+++ 
b/maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScanner.java
@@ -142,7 +142,14 @@ protected void scan( Map 
mojoAnnotatedClasses, File
 {
 continue;
 }
-analyzeClassStream( mojoAnnotatedClasses, archiveStream, 
artifact, excludeMojo );
+try
+{
+analyzeClassStream( mojoAnnotatedClasses, archiveStream, 
artifact, excludeMojo );
+}
+catch ( ArrayIndexOutOfBoundsException e )
+{
+getLogger().warn( "Error analyzing class " + zipEntryName 
);
+}
 }
 }
 catch ( IllegalArgumentException e )


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] dheid commented on issue #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188

2018-02-02 Thread GitBox 
dheid commented on issue #11: MPLUGIN-328 ArrayIndexOutOfBoundsException: 48188
URL: https://github.com/apache/maven-plugin-tools/pull/11#issuecomment-362528887
 
 
   Maintainer fixed it on his own.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services