[jira] [Commented] (MNG-6308) display packaging when building a module

[Michael Osipov (JIRA)]

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

Michael Osipov commented on MNG-6308:
-

The packaging in the HR line looks pretty displaced for me. It should rather be 
in the same line as [x/y]. The reactor build order summary looks fine though.

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] chonton commented on issue #1: fix DeployAtEnd failures

[GitBox]

chonton commented on issue #1: fix DeployAtEnd failures
URL: https://github.com/apache/maven-deploy-plugin/pull/1#issuecomment-350582953
 
 
   Same PR as https://github.com/apache/maven-plugins/pull/138.


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] chonton opened a new pull request #1: fix DeployAtEnd failures

[GitBox]

chonton opened a new pull request #1: fix DeployAtEnd failures
URL: https://github.com/apache/maven-deploy-plugin/pull/1
 
 
   MDEPLOY-226: DeployAtEnd fails when module has extension
   MDEPLOY-225: DeployAtEnd fails when overriding skip
   MDEPLOY-224: Overriding deployAtEnd fails


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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
I do not have questions yet. I am just reading your comments. I would think 
of the code combining together with Cucumber internals and then I would have 
maybe some notice.


> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
I do not have questions yet. I am just reading your comments. I would think 
of the code combining together with Cucumber internals and then I would have 
maybe some notice.


---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@Tibor17 please let me know if you have more questions.


> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
I haven't answered yet is why cucumber creates descriptions with a unique 
Id and doesn't just use the method names. 

The reason for that is that scenarios in cucumber don't need to have unique 
names. While we could use a URI instead this would result in a rather hideous 
display name. We like to keep things friendly so we use the Id.

Other use cases include frameworks that repeatedly execute the same test 
method with different parameters. Each invocation would have it's own id while 
the method and test name would be the same.




> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@Tibor17 please let me know if you have more questions.


---

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

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
I haven't answered yet is why cucumber creates descriptions with a unique 
Id and doesn't just use the method names. 

The reason for that is that scenarios in cucumber don't need to have unique 
names. While we could use a URI instead this would result in a rather hideous 
display name. We like to keep things friendly so we use the Id.

Other use cases include frameworks that repeatedly execute the same test 
method with different parameters. Each invocation would have it's own id while 
the method and test name would be the same.




---

[jira] [Comment Edited] (MNG-6308) display packaging when building a module

[JIRA]

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

Hervé Boutemy edited comment on MNG-6308 at 12/10/17 4:44 PM:
--

sure, one can avoid defining $\{project.packaging} then put just pom to not 
benefit from default plugin bindings to lifecycle

but in general, if we defined default plugin bindings based on 
$\{project.packaging} value, it's because in general this defines the expected 
default build: explicitely adding some plugins is just some little additional 
build customization

notice: probably we should have put this element in build, then have 
$\{project.build.packaging}, but now the habit is to have this build info near 
groupId/artifactId/version


was (Author: hboutemy):
sure, one can avoid defining $\{project.packaging} then put just pom to not 
benefit from default plugin bindings to lifecycle

but in general, if we defined default plugin bindings based on 
$\{project.packaging} value, it's because in general this defines the expected 
default build: explicitely adding some plugins is just some little additional 
build customization

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WAGON-493) Maven wagon-scm documentation is erroneous

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WAGON-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285312#comment-16285312
 ] 

ASF GitHub Bot commented on WAGON-493:
--

GitHub user Tcharl opened a pull request:

https://github.com/apache/maven-wagon/pull/38

wagon-scm documentation update

https://issues.apache.org/jira/browse/WAGON-493

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

$ git pull https://github.com/Tcharl/maven-wagon master

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

https://github.com/apache/maven-wagon/pull/38.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 #38


commit 56168d5f2932cea77bf2df43098cca117cdf6583
Author: charlie 
Date:   2017-12-10T16:42:35Z

documentation update, fixes https://issues.apache.org/jira/browse/WAGON-493




> Maven wagon-scm documentation is erroneous
> --
>
> Key: WAGON-493
> URL: https://issues.apache.org/jira/browse/WAGON-493
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-scm
>Affects Versions: 3.0.0
>Reporter: Charlie Mordant
>Priority: Critical
>
> The documentation stated many wrong things:
> * Using extensions for providers does not work with maven-site-pg: you should 
> use site-plugin dependency section instead
> * The scmVersionType and scmVersion tags on settings shall be enclosed by a 
> {code:xml}
> 
> {code}
> Section.
> Regards,
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] maven-wagon pull request #38: wagon-scm documentation update

[Tcharl]

GitHub user Tcharl opened a pull request:

https://github.com/apache/maven-wagon/pull/38

wagon-scm documentation update

https://issues.apache.org/jira/browse/WAGON-493

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

$ git pull https://github.com/Tcharl/maven-wagon master

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

https://github.com/apache/maven-wagon/pull/38.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 #38


commit 56168d5f2932cea77bf2df43098cca117cdf6583
Author: charlie 
Date:   2017-12-10T16:42:35Z

documentation update, fixes https://issues.apache.org/jira/browse/WAGON-493




---

[jira] [Comment Edited] (MNG-6308) display packaging when building a module

[JIRA]

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

Hervé Boutemy edited comment on MNG-6308 at 12/10/17 4:42 PM:
--

sure, one can avoid defining $\{project.packaging} then put just pom to not 
benefit from default plugin bindings to lifecycle

but in general, if we defined default plugin bindings based on 
$\{project.packaging} value, it's because in general this defines the expected 
default build: explicitely adding some plugins is just some little additional 
build customization


was (Author: hboutemy):
sure, one can avoid defining ${project.packaging} then put just pom to not 
benefit from default plugin bindings to lifecycle

but in general, if we defined default plugin bindings based on 
${project.packaging} value, it's because in general this defines the expected 
default build: explicitely adding some plugins is just some little additional 
build customization

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6308) display packaging when building a module

[JIRA]

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

Hervé Boutemy commented on MNG-6308:


sure, one can avoid defining ${project.packaging} then put just pom to not 
benefit from default plugin bindings to lifecycle

but in general, if we defined default plugin bindings based on 
${project.packaging} value, it's because in general this defines the expected 
default build: explicitely adding some plugins is just some little additional 
build customization

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
> Additionally, can you write a separate documentation file cucumber.apt.vm 
for Cucumber with your best practices to setup and use cucumber in terms of 
maven-surefire-plugin and maven-failsafe-plugin tests, annotations like 
CucumberOptions, dependencies, versions, configuration if any, and re-run 
notices?

Sure!


> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
> Additionally, can you write a separate documentation file cucumber.apt.vm 
for Cucumber with your best practices to setup and use cucumber in terms of 
maven-surefire-plugin and maven-failsafe-plugin tests, annotations like 
CucumberOptions, dependencies, versions, configuration if any, and re-run 
notices?

Sure!


---

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

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
> Why you have chosen provider surefire-junit47 and not also the 
surefire-junit4?

While it would be possible to change surefire-junit4 to filter by 
description there is no need to. Prior to JUnit 4.11 descriptions use their 
display name to test for equality. The display name was composed of a method 
name and a class name. As such filtering by a description created from the 
method and class name of a failed test and filtering by the description of that 
failed test will yield the same result.

```java
Description failedTestDescription = 
Description.createTestDescription(Test.class, "shouldTestSomething");
Description descriptionFromFailedMethodAndClassName = 
Description.createTestDescription(Test.class, "shouldTestSomething");

assertEquals(failedTestDescription, 
descriptionFromFailedMethodAndClassName);
assertEquals(failedTestDescription.getDisplayName(), 
descriptionFromFailedMethodAndClassName.getDisplayName());
```

> Why the method generateFailingTestDescriptions has to return 
Set and not the previous Map?

With the introduction of the `fUniqueId` property to test for equality 
between descriptions in JUnit 4.11 filtering by a description created from the 
method and class name of a failed test and filtering by the description of that 
failed test are no longer the same. Hence the need to use the description of 
the failed test instead of its method and class name.

For example:

```java
Description failedTestDescription = 
Description.createTestDescription(Test.class.getCanonicalName(), 
"shouldTestSomething", "my-test-id");
Description descriptionFromFailedMethodAndClassName = 
Description.createTestDescription(Test.class, "shouldTestSomething");


assertNotEquals(failedTestDescription, 
descriptionFromFailedMethodAndClassName);
assertEquals(failedTestDescription.getDisplayName(), 
descriptionFromFailedMethodAndClassName.getDisplayName());
```







---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
> Why you have chosen provider surefire-junit47 and not also the 
surefire-junit4?

While it would be possible to change surefire-junit4 to filter by 
description there is no need to. Prior to JUnit 4.11 descriptions use their 
display name to test for equality. The display name was composed of a method 
name and a class name. As such filtering by a description created from the 
method and class name of a failed test and filtering by the description of that 
failed test will yield the same result.

```java
Description failedTestDescription = 
Description.createTestDescription(Test.class, "shouldTestSomething");
Description descriptionFromFailedMethodAndClassName = 
Description.createTestDescription(Test.class, "shouldTestSomething");

assertEquals(failedTestDescription, 
descriptionFromFailedMethodAndClassName);
assertEquals(failedTestDescription.getDisplayName(), 
descriptionFromFailedMethodAndClassName.getDisplayName());
```

> Why the method generateFailingTestDescriptions has to return 
Set and not the previous Map?

With the introduction of the `fUniqueId` property to test for equality 
between descriptions in JUnit 4.11 filtering by a description created from the 
method and class name of a failed test and filtering by the description of that 
failed test are no longer the same. Hence the need to use the description of 
the failed test instead of its method and class name.

For example:

```java
Description failedTestDescription = 
Description.createTestDescription(Test.class.getCanonicalName(), 
"shouldTestSomething", "my-test-id");
Description descriptionFromFailedMethodAndClassName = 
Description.createTestDescription(Test.class, "shouldTestSomething");


assertNotEquals(failedTestDescription, 
descriptionFromFailedMethodAndClassName);
assertEquals(failedTestDescription.getDisplayName(), 
descriptionFromFailedMethodAndClassName.getDisplayName());
```







> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (ARCHETYPE-537) fileset exclude or include on conditions

[Dong Xu (JIRA)]

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

Dong Xu updated ARCHETYPE-537:
--
Description: 
I think this will be an useful feature:
maven archetype user can choose to include files or not according to a required 
property.
For Example:
I am xxx-archetype developer, and I set "*useRedis*" as one required property. 
Now some guys want to use xxx-archetype, so if he give a "N" value to this 
property ,  the "*src/main/resources/spring/redis.xml*" will be excluded. 
Otherwise,  the generated project will include 
"*src/main/resources/spring/redis.xml*".

  was:
I think this will be an useful feature:
maven archetype user can choose to include a component or not according to a 
required property.
For Example:
I am xxx-archetype developer, and I set "*useRedis*" as one required property. 
Now some guys want to use xxx-archetype, so if he give a "N" value to this 
property ,  the "*src/main/resources/spring/redis.xml*" will be excluded. 
Otherwise,  the generated project will include 
"*src/main/resources/spring/redis.xml*".


> fileset exclude or include on conditions
> 
>
> Key: ARCHETYPE-537
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-537
> Project: Maven Archetype
>  Issue Type: New Feature
>  Components: Archetypes
>Affects Versions: 3.0.1
> Environment: 
>Reporter: Dong Xu
>  Labels: features
>
> I think this will be an useful feature:
> maven archetype user can choose to include files or not according to a 
> required property.
> For Example:
> I am xxx-archetype developer, and I set "*useRedis*" as one required 
> property. 
> Now some guys want to use xxx-archetype, so if he give a "N" value to this 
> property ,  the "*src/main/resources/spring/redis.xml*" will be excluded. 
> Otherwise,  the generated project will include 
> "*src/main/resources/spring/redis.xml*".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
 > How is Description constructed now by Cucumber?

Executing cucumber while using JUnit creates a tree of Descriptions like so:

```
Cucumber
 |- Feature 1
 |  | - Scenario 1
 |  | - Scenario 2
 |  | - Scenario 3
 |- Feature 2
 |  | - Scenario 4
 |  | - Scenario 5
 |  | - Scenario 6
```

The root description describes the [Cucumber JUnit 
runner](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/api/junit/Cucumber.java)
 and is created in [JUnits 
ParentRunner](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runners/ParentRunner.java#L349).
 using 
[Description.createSuitDescription(String)](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L44).
 This results in a `Description` with `fUniqueId` equal to the name of  the 
runner. This is always the fqn of the JUnit test annotated with 
`@RunWith(Cucumber.class)`.

The Feature Descriptions are created in the 
[FeatureRunner](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/runtime/junit/FeatureRunner.java#L44)
 using [Description.createSuitDescription(String, 
Serializable)](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L57).
 The name is name of the, which is used for display purposes but otherwise 
irrelevant. For the extra `Serializable` parameter we provide a 
[FeatureId](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/runtime/junit/FeatureRunner.java#L105).
 This results in a `Description` with `fUniqueId` equal to the `FeatureId` of 
that feature. This `FeatureId` contains the features uri which will satisfy 
equality between different (repeated) executions of the same test class.

The same reasoning applies to the creation of the scenario description. 
Each `Description` is created with a `PickleId` that contains the uri of that 
scenario. The actual implementation is slightly more complex so I'd like to 
omit it for brevity.

As such we end up with:

```
Cucumber   Description.fUniqueId = 
"com.example.package.of.my.RunnerTest"
 |- Feature 1  Description.fUniqueId = 
FeatureId("path/to/my/cucumber.feature1")
 |  | - Scenario 1 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:1")
 |  | - Scenario 2 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:2")
 |  | - Scenario 3 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:3")
 |- Feature 2  Description.fUniqueId = 
FeatureId("path/to/my/cucumber.feature2")
 |  | - Scenario 4 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:1")
 |  | - Scenario 5 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:2")
 |  | - Scenario 6 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:3")
```

> Does it contain the real method name or it is a scenario text?

No. It does not contain a method name. A scenario does not have a 
one-to-one mapping with any methods. Instead we use uri's to reference a 
scenario. Note that if we were to rewrite the above suite of features to a 
suite of JUnit tests, the underlying `Description` tree would have a similar 
identity.

```
TestSuite  Description.fUniqueId = 
"com.example.package.of.my.TestSuite"
 |- Feature 1  Description.fUniqueId = 
"com.example.package.of.my.Feature1"
 |  | - Scenario 1 Description.fUniqueId = 
"scenario1(com.example.package.of.my.Feature1)"
 |  | - Scenario 2 Description.fUniqueId = 
"scenario2(com.example.package.of.my.Feature1)"
 |  | - Scenario 3 Description.fUniqueId = 
"scenario3(com.example.package.of.my.Feature1)"
 |- Feature 2  Description.fUniqueId =  
"com.example.package.of.my.TestSuite"
 |  | - Scenario 4 Description.fUniqueId = 
"scenario1(com.example.package.of.my.Feature2)"
 |  | - Scenario 5 Description.fUniqueId = 
"scenario2(com.example.package.of.my.Feature2)"
 |  | - Scenario 6 Description.fUniqueId = 
"scenario3(com.example.package.of.my.Feature2)"
```


> 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 

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

[mpkorstanje]

Github user mpkorstanje commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
 > How is Description constructed now by Cucumber?

Executing cucumber while using JUnit creates a tree of Descriptions like so:

```
Cucumber
 |- Feature 1
 |  | - Scenario 1
 |  | - Scenario 2
 |  | - Scenario 3
 |- Feature 2
 |  | - Scenario 4
 |  | - Scenario 5
 |  | - Scenario 6
```

The root description describes the [Cucumber JUnit 
runner](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/api/junit/Cucumber.java)
 and is created in [JUnits 
ParentRunner](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runners/ParentRunner.java#L349).
 using 
[Description.createSuitDescription(String)](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L44).
 This results in a `Description` with `fUniqueId` equal to the name of  the 
runner. This is always the fqn of the JUnit test annotated with 
`@RunWith(Cucumber.class)`.

The Feature Descriptions are created in the 
[FeatureRunner](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/runtime/junit/FeatureRunner.java#L44)
 using [Description.createSuitDescription(String, 
Serializable)](https://github.com/junit-team/junit4/blob/r4.12/src/main/java/org/junit/runner/Description.java#L57).
 The name is name of the, which is used for display purposes but otherwise 
irrelevant. For the extra `Serializable` parameter we provide a 
[FeatureId](https://github.com/cucumber/cucumber-jvm/blob/v2.2.0/junit/src/main/java/cucumber/runtime/junit/FeatureRunner.java#L105).
 This results in a `Description` with `fUniqueId` equal to the `FeatureId` of 
that feature. This `FeatureId` contains the features uri which will satisfy 
equality between different (repeated) executions of the same test class.

The same reasoning applies to the creation of the scenario description. 
Each `Description` is created with a `PickleId` that contains the uri of that 
scenario. The actual implementation is slightly more complex so I'd like to 
omit it for brevity.

As such we end up with:

```
Cucumber   Description.fUniqueId = 
"com.example.package.of.my.RunnerTest"
 |- Feature 1  Description.fUniqueId = 
FeatureId("path/to/my/cucumber.feature1")
 |  | - Scenario 1 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:1")
 |  | - Scenario 2 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:2")
 |  | - Scenario 3 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature1:3")
 |- Feature 2  Description.fUniqueId = 
FeatureId("path/to/my/cucumber.feature2")
 |  | - Scenario 4 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:1")
 |  | - Scenario 5 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:2")
 |  | - Scenario 6 Description.fUniqueId = 
PickleId("path/to/my/cucumber.feature2:3")
```

> Does it contain the real method name or it is a scenario text?

No. It does not contain a method name. A scenario does not have a 
one-to-one mapping with any methods. Instead we use uri's to reference a 
scenario. Note that if we were to rewrite the above suite of features to a 
suite of JUnit tests, the underlying `Description` tree would have a similar 
identity.

```
TestSuite  Description.fUniqueId = 
"com.example.package.of.my.TestSuite"
 |- Feature 1  Description.fUniqueId = 
"com.example.package.of.my.Feature1"
 |  | - Scenario 1 Description.fUniqueId = 
"scenario1(com.example.package.of.my.Feature1)"
 |  | - Scenario 2 Description.fUniqueId = 
"scenario2(com.example.package.of.my.Feature1)"
 |  | - Scenario 3 Description.fUniqueId = 
"scenario3(com.example.package.of.my.Feature1)"
 |- Feature 2  Description.fUniqueId =  
"com.example.package.of.my.TestSuite"
 |  | - Scenario 4 Description.fUniqueId = 
"scenario1(com.example.package.of.my.Feature2)"
 |  | - Scenario 5 Description.fUniqueId = 
"scenario2(com.example.package.of.my.Feature2)"
 |  | - Scenario 6 Description.fUniqueId = 
"scenario3(com.example.package.of.my.Feature2)"
```


---

[jira] [Commented] (SUREFIRE-1444) /usr/bin/ps and /bin/ps not found. Forked JVM fails.

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1444:


[~rfsnjb]
I have several questions, so pls answer them all. Your answer would help me to 
find root cause of the bug in Surefire.
Did you run your project on Linux?
Did you run Docker on Windows? If so, the docker can run {{wmic.exe}} library? 
Please try!
If you did not run Surefire in Docker, try to run library {{wmic.exe}} and tell 
me if it is alive.

> /usr/bin/ps and /bin/ps not found. Forked JVM fails.
> 
>
> Key: SUREFIRE-1444
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1444
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1
> Environment: Windows 7 Pro 64 bits
> Maven 3.5.2 , jdk 1.8.0_152
>Reporter: rfs
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
> Attachments: dump.txt, mavenlog.txt
>
>
> mvn test is failed with maven 3.5.2, jdk 1.8.0_x, maven surefire 2.20.1
> maven repository is deleted before but same result.
> mvn test is successfull with maven 3.5.2, jdk 1.8.0_x, maven surefire 2.19.1
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 9.490 s
> [INFO] Finished at: 2017-11-16T08:58:19+01:00
> [INFO] Final Memory: 35M/290M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on 
> project project-name: There are test fa
> ilures.
> [ERROR]
> [ERROR] Please refer to R:\src\project-name\target\surefire-reports for the 
> individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was cmd.exe /X /C "R:\tools\jdk1.8.0_152\jre\bin\java -jar 
> d:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195\sur
> efirebooter7359328160006854832.jar 
> D:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195 
> 2017-11-16T08-58-14_352-jvmRun1 surefire80634
> 62497440390334tmp surefire_0627218662296028436tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exi
> t called?
> [ERROR] Command was cmd.exe /X /C "R:\tools\jdk1.8.0_152\jre\bin\java -jar 
> d:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195\sur
> efirebooter7359328160006854832.jar 
> D:\Profiles\XXX\AppData\Local\Temp\surefire4973827123764606195 
> 2017-11-16T08-58-14_352-jvmRun1 surefire80634
> 62497440390334tmp surefire_0627218662296028436tmp"
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] Process Exit Code: 1
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:686)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:535)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:280)
> [ERROR] at 
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1124)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> [ERROR] at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> [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 
> 

[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/166
  
@krmahadevan 
Do you have a spare time for Surefire?
This is good work but there is only a little to do: checkstyle and Jira 
ticket.


---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
I want to ask you few question because I want to make minimum invasive 
changes in the code.
Why you have chosen provider `surefire-junit47` and not also the 
`surefire-junit4`?
Why the method `generateFailingTestDescriptions` has to return 
`Set` and not the previous `Map`?


> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
I want to ask you few question because I want to make minimum invasive 
changes in the code.
Why you have chosen provider `surefire-junit47` and not also the 
`surefire-junit4`?
Why the method `generateFailingTestDescriptions` has to return 
`Set` and not the previous `Map`?


---

[jira] [Commented] (MNG-6308) display packaging when building a module

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6308:
-

javadoc and sources are attachments, but in the end it is only packaging, 
installing and deploying.
I've talked with [~stephenc] about this for Model 5.0.0. My example is the 
soapui-maven-plugin, which can generate a web archive for a mockservice. The 
packaging should be war based on the resulting file type, but that comes with 
too much overhead. the pom-lifecycle should be enough.
This example shows that packaging is not always interesting, IMHO adding 
package info can cause unintended confusion.

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MSKINS-139) add edit button to link to scm source

[JIRA]

Hervé Boutemy created MSKINS-139:


 Summary: add edit button to link to scm source
 Key: MSKINS-139
 URL: https://issues.apache.org/jira/browse/MSKINS-139
 Project: Maven Skins
  Issue Type: Improvement
  Components: Fluido Skin
Affects Versions: fluido-1.6
Reporter: Hervé Boutemy
 Fix For: fluido-1.7


to ease Doxia source file finding, then ease contribution of PRs on the site

requires DOXIASITETOOLS-181



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] maven-surefire issue #165: Merge master to junit5

[britter]

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/165
  
@Tibor17 

> What about if I squash your commits to one? And then it would go to a new 
branch based on master current HEAD?
> This branch has old history.

Let's do it like this!

> Question, Do you have anything in our code to add regarding junit5 
activity? You know best.




---

[jira] [Created] (DOXIASITETOOLS-181) add docRenderingContext to template Velocity context

[JIRA]

Hervé Boutemy created DOXIASITETOOLS-181:


 Summary: add docRenderingContext to template Velocity context
 Key: DOXIASITETOOLS-181
 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-181
 Project: Maven Doxia Sitetools
  Issue Type: Improvement
  Components: Site renderer
Affects Versions: 1.7.5
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: 1.8.0


this will permit calculations about Doxia input file, i.e. the source file, 
useful to generate an edit icon that will link to the source file in scm



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MNG-6308) display packaging when building a module

[JIRA]

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

Hervé Boutemy edited comment on MNG-6308 at 12/10/17 8:52 AM:
--

re-reading once more 
http://maven.apache.org/ref/3.5.2/maven-core/artifact-handlers.html
I don't think having a packaging attribute on artifact handlers has really a 
meaning: javadoc packaging does not exist, not java-source
I really feel that there is a misconception here (and I suppose that this 
getPackaging() method isn't used anywhere since it does not really have any 
meaning)

and when we read the documentation for type in pom's dependency 
http://maven.apache.org/ref/3.5.2/maven-model/maven.html#class_dependency , 
this misconception is apparent by the vague explanations


was (Author: hboutemy):
re-reading once more 
http://maven.apache.org/ref/3.5.2/maven-core/artifact-handlers.html
I don't think having a packaging attribute on artifact handlers has really a 
meaning: javadoc packaging does not exist, not java-source
I really feel that there is a misconception here (and I suppose that this 
getPackaging() method isn't used anywhere since it does not really have any 
meaning)

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6308) display packaging when building a module

[JIRA]

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

Hervé Boutemy commented on MNG-6308:


re-reading once more 
http://maven.apache.org/ref/3.5.2/maven-core/artifact-handlers.html
I don't think having a packaging attribute on artifact handlers has really a 
meaning: javadoc packaging does not exist, not java-source
I really feel that there is a misconception here (and I suppose that this 
getPackaging() method isn't used anywhere since it does not really have any 
meaning)

> display packaging when building a module
> 
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is 
> short and should be visible in the build log
> proposal:
> {code}[INFO] 
> 
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] ---  pom  
> --{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
Additionally, can you write a separate documentation file `cucumber.apt.vm` 
for Cucumber with your best practices to setup and use cucumber in terms of 
`maven-surefire-plugin` and `maven-failsafe-plugin` tests, annotations like 
`CucumberOptions`, dependencies, versions, configuration if any, and `re-run` 
notices?
Take a notice that `maven-failsafe-plugin` has name or class *IT but 
`maven-surefire-plugin` has *Test.
The files in folder `examples` will show you how to cope with both plugins 
and alter the text.
The file `cucumber.apt.vm`  should be located in 
`maven-surefire-plugin/src/site/apt/examples`.
And add the following to `site.xml`:
``



> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
Additionally, can you write a separate documentation file `cucumber.apt.vm` 
for Cucumber with your best practices to setup and use cucumber in terms of 
`maven-surefire-plugin` and `maven-failsafe-plugin` tests, annotations like 
`CucumberOptions`, dependencies, versions, configuration if any, and `re-run` 
notices?
Take a notice that `maven-failsafe-plugin` has name or class *IT but 
`maven-surefire-plugin` has *Test.
The files in folder `examples` will show you how to cope with both plugins 
and alter the text.
The file `cucumber.apt.vm`  should be located in 
`maven-surefire-plugin/src/site/apt/examples`.
And add the following to `site.xml`:
``



---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
How is `Description` constructed now by Cucumber?
Does it contain the real method name or it is a scenario text?



> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/150
  
@mpkorstanje 
How is `Description` constructed now by Cucumber?
Does it contain the real method name or it is a scenario text?



---

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1372:
--

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/150#discussion_r155940679
  
--- Diff: 
surefire-integration-tests/src/test/resources/junit47-rerun-failing-tests-with-cucumber/pom.xml
 ---
@@ -0,0 +1,79 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+
+
+junit47-rerun-failing-tests-with-cucumber
+jar
--- End diff --

jar packaging is default one. You don't need to specify it.


> 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
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses 
> {noformat}Description#createSuiteDescription{noformat} with a human readable 
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create 
> test class 'Scenario: Fail when running'
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Tibor17]

Github user Tibor17 commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/150#discussion_r155940679
  
--- Diff: 
surefire-integration-tests/src/test/resources/junit47-rerun-failing-tests-with-cucumber/pom.xml
 ---
@@ -0,0 +1,79 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+
+
+junit47-rerun-failing-tests-with-cucumber
+jar
--- End diff --

jar packaging is default one. You don't need to specify it.


---