[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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...
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
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/WAGON-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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...
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, Set>? 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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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, Set>?
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
[ 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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 Plugi
[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...
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.
[
https://issues.apache.org/jira/browse/SUREFIRE-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(Single
[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...
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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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, Set>`?
> 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...
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, Set>`? ---
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
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
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
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ...
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. ---
