[jira] [Commented] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029610#comment-17029610 ] Herve Boutemy commented on MNG-6789: notice: the timestamp value is accurate for releases, but not for SNAPSHOTs, where its value will be the timestamp of the previous release > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap & Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029605#comment-17029605 ] Herve Boutemy commented on MNG-6789: if you want: just create a separate Jira issue, please > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap & Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6848) Ci Friendly builds broke with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029493#comment-17029493
]
Patrick Barry commented on MNG-6848:
We use "version" to represent the base version shared by parent and child
modules. Seems silly to have to use the versions plugin just to change all of
the versions in a project when this could be accomplished using one variable
defined in the parent. This was a warning until the PR Jason mentioned above,
merged. If this needed to be an error and fail the build, wouldn't that be
documented in changelog and have a major version bump according to semver?
> Ci Friendly builds broke with 3.6.2
> ---
>
> Key: MNG-6848
> URL: https://issues.apache.org/jira/browse/MNG-6848
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Patrick Barry
>Priority: Major
>
> We currently use ci friendly versions introduced in 3.5.0
> [https://maven.apache.org/docs/3.5.0/release-notes.html] Using of CI friendly
> versions via ${revision}, ${sha1} and/or ${changelist} has been fixed
> MNG-6057, MNG-6090 and MNG-5895. It is very important to know if you are
> using the previously named properties for a version in your pom you have to
> use flatten-maven-plugin if you like to do an mvn install or mvn deploy more
> details can be found at Maven CI Friendly Versions.
>
> Our parent pom are defined with the following version attributes:
> {code:java}
> ${version}${revision}
> pom
> com.group
> my-proj
>
>0.0.1
>-SNAPSHOT
>
> {code}
> and then on our build machine, we mvn install -Drevision=
> our sub-modules inherit the version from parent like this:
> {code:java}
>
> com.group
> my-proj
>
> ${version}${revision}
> ..
>
> {code}
> This allows us to only have to define the version in one spot and all
> sub-modules will stay in sync with parent.
> This generated a warning but still worked until 3.6.2
> {noformat}
> 15:56:14 [WARNING] Some problems were encountered while building the
> effective model for com.group:little-proj:jar:2.0.0.48015:56:14 [WARNING]
> 'version' contains an expression but should be a constant. @
> com.group:my-proj:${version}${revision},
> /var/build/workspace/project/pom.xml, line 17, column 14{noformat}
> is now...
> {noformat}
> 15:54:12 [ERROR] 'dependencies.dependency.version' for
> com.group:little-proj:jar is missing. @
> com.group:test-proj:${version}${revision},
> /var/build/workspace/test/./test-proj/pom.xml, line 89, column 22{noformat}
> we use flatten plugin
> {code:java}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.1.0
>
>
> flatten
> process-resources
>
> flatten
>
>
> true
> resolveCiFriendliesOnly
>
>
>
> flatten.clean
> clean
>
> clean
>
>
>
>
> true
> resolveCiFriendliesOnly
>
> {code}
> If this is not the proper way to use Ci-Friendly versions, what is?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6858) Need a way to skip empty-string arguments
[
https://issues.apache.org/jira/browse/MNG-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029357#comment-17029357
]
Chris Hennick commented on MNG-6858:
[~khmarbaise] Is there, by any chance, a way to automatically audit all my
Maven invocations for similarly redundant steps? (Note that running the same
unit tests in Surefire and Failsafe is not redundant, because it lets me
collect a coverage report _and_ detect breakages caused by the Proguard config.
Proguard is the pre-integration-test step, but I'm not sure that's the optimal
place for it; my project's lifecycle doesn't seem to match any documented
examples.)
> Need a way to skip empty-string arguments
> -
>
> Key: MNG-6858
> URL: https://issues.apache.org/jira/browse/MNG-6858
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.1
> Environment: Ubuntu 19.10
>Reporter: Chris Hennick
>Priority: Major
>
> I have a bash script that sets a sometimes-empty variable as follows:
>
> {code:java}
> if [ "${ANDROID}" = "true" ]; then
> MAYBE_ANDROID_FLAG=-Pandroid
> else
> MAYBE_ANDROID_FLAG=
> fi{code}
>
> It's used like so:
>
> {code:java}
> mvn ${MAYBE_ANDROID_FLAG} clean compile jacoco:instrument
> jacoco:prepare-agent test jacoco:restore-instrumented-classes jacoco:report
> -e -B}}{code}
>
> Shell-scripting best practices dictate that ${MAYBE_ANDROID_FLAG} above
> should be in double quotes, but when I do that, I get 'Unknown lifecycle
> phase ""'. For it to be possible to follow best practices, then, we need a
> way to make Maven skip over command-line arguments that are empty strings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6858) Need a way to skip empty-string arguments
[
https://issues.apache.org/jira/browse/MNG-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029356#comment-17029356
]
Chris Hennick commented on MNG-6858:
[~khmarbaise] Thanks; I'm testing the script without the explicit compile.
> Need a way to skip empty-string arguments
> -
>
> Key: MNG-6858
> URL: https://issues.apache.org/jira/browse/MNG-6858
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.1
> Environment: Ubuntu 19.10
>Reporter: Chris Hennick
>Priority: Major
>
> I have a bash script that sets a sometimes-empty variable as follows:
>
> {code:java}
> if [ "${ANDROID}" = "true" ]; then
> MAYBE_ANDROID_FLAG=-Pandroid
> else
> MAYBE_ANDROID_FLAG=
> fi{code}
>
> It's used like so:
>
> {code:java}
> mvn ${MAYBE_ANDROID_FLAG} clean compile jacoco:instrument
> jacoco:prepare-agent test jacoco:restore-instrumented-classes jacoco:report
> -e -B}}{code}
>
> Shell-scripting best practices dictate that ${MAYBE_ANDROID_FLAG} above
> should be in double quotes, but when I do that, I get 'Unknown lifecycle
> phase ""'. For it to be possible to follow best practices, then, we need a
> way to make Maven skip over command-line arguments that are empty strings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029342#comment-17029342
]
Albert Johnston commented on SUREFIRE-1748:
---
I'm sure I checked that at one point, specifically comparing the difference
between a SimpleReportEntry created from AssertionError (JUnit4) and
AssertionFailedError (JUnit 5), and both had the stack trace, but I'll double
check.
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1217)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1063)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:889){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029336#comment-17029336
]
Tibor Digana commented on SUREFIRE-1748:
I am sure we are not sending the stack trace to the RunAdapter via
SimpleReportEntry while the failure happens.
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1217)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1063)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:889){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029311#comment-17029311
]
Albert Johnston commented on SUREFIRE-1748:
---
Yes, it's the same line.
[https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/DefaultReporterFactory.java#L398]
The line is:
{code:java}
failure( " " + testMethodStats.get( 0
).getStackTraceWriter().smartTrimmedStackTrace() );
{code}
I've already looked into this a couple times, once for a few minutes to see if
it was a simple fix, and a second time for an hour or so to really dig around
for the issue. I can say with certainty that the returned null value is the
{code:java}
getStackTraceWriter(){code}
causing the NPE when
{code:java}
smartTrimmedStackTrace(){code}
is called. Although I'm not at all familiar with this part of the project, I'm
inclined to believe that the issue isn't here. Especially considering the fact
that this issue doesn't happen with JUnit4's Assert.fail(), even if you
explicitly pass in null. I think it's likely that there's a check somewhere
else that's treating JUnit 5's assert differently, but it's really just
conjecture. I even tried manually changing a few of those places to return a
non-null value, but nothing helped. I was focusing on this in particular at one
point, but again, didn't help:
[https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-java5/src/main/java/org/apache/maven/surefire/report/SmartStackTraceParser.java#L133]
I'll give it another shot tonight, it's been a few days, maybe coming at it
fresh will help. Also, if you have any thoughts, I'm open to ideas.
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
>
[jira] [Commented] (SUREFIRE-681) Add timestamp when each test is run in the generated report
[
https://issues.apache.org/jira/browse/SUREFIRE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029264#comment-17029264
]
Tibor Digana commented on SUREFIRE-681:
---
[~finn_desolace]
I understand your business problem.
Can you have a look in our XSD schema [1] and show me where you expect the
timestamp?
[1]:
https://github.com/apache/maven-surefire/blob/master/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report-3.0.xsd
> Add timestamp when each test is run in the generated report
> ---
>
> Key: SUREFIRE-681
> URL: https://issues.apache.org/jira/browse/SUREFIRE-681
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Viggo Navarsete
>Priority: Major
> Fix For: Backlog
>
>
> We run integration tests using maven-surefire-plugin by filtering on the
> names (they end with *TestIntegration). These tests access a JBoss server,
> and leave log entires in the server log. When a test fail, it would be great
> to have a timestamp on each test in the test report from surefire so that it
> can be matched against what is happening in the server log. This is
> especially true when you have a lot of integration tests running and you
> can't directly spot the server log entries related to the failing test. By
> adding a timestamp to the tests it would make it MUCH easier to figure out
> the server log dependent calls.
> Current output:
> {noformat}
> ---
> Test set: com.tracetracker.gqi3.QueryRestTestIntegration
> ---
> Tests run: 17, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.546 sec
> <<< FAILURE!
> testSimpleEventQueryRecordTime(com.tracetracker.gqi3.QueryRestTestIntegration)
> Time elapsed: 0.031 sec <<< FAILURE!
> junit.framework.AssertionFailedError: List of recordTime should not be empty
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> com.tracetracker.gqi3.QueryRestTestIntegration.testSimpleEventQueryRecordTime(QueryRestTestIntegration.java:283)
> {noformat}
> Each failing test should have the timestamp added to the start of the line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029259#comment-17029259
]
Tibor Digana commented on SUREFIRE-1748:
You have experiences with our code. Can you analyse or debug
{{DefaultReporterFactory}}?
Is it the same line 398 in origin/master?
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1217)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1063)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:889){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-346) Introduce mock repository manager for testing
[ https://issues.apache.org/jira/browse/MSHADE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029244#comment-17029244 ] Hudson commented on MSHADE-346: --- Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » master #53 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/53/ > Introduce mock repository manager for testing > - > > Key: MSHADE-346 > URL: https://issues.apache.org/jira/browse/MSHADE-346 > Project: Maven Shade Plugin > Issue Type: Task >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.2.2 > > > The mock repository manager removes the need for jars in the sourcecode. > This way it will be clear which content is tested. > It will also remove the bad practice of repositories in poms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6836) Too Many Open Files for large projects
[ https://issues.apache.org/jira/browse/MNG-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029242#comment-17029242 ] Karl Heinz Marbaise commented on MNG-6836: -- I had much larger projects which had about 800+ modules with different types etc. without any such issues...If I correctly remember the maven-pmd-plugin was not part of that? > Too Many Open Files for large projects > -- > > Key: MNG-6836 > URL: https://issues.apache.org/jira/browse/MNG-6836 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.5.2, 3.5.3, 3.5.4, 3.6.0, 3.6.1, 3.6.2, 3.6.3 >Reporter: Cody Wayne Holmes >Priority: Major > > This issue seems to be that all plugins classloaders are created and then > cached, and plugins are internally creating classloaders that are not being > closed and therefore leaving open file handles to jar files waiting to be > finalized. > > When a project gets big enough with enough modules and plugins than this > becomes a problem as the project will reach a large number of open jar files > by the time it completes and if the file system is not set up to allow the > standard ulimit to be exceeded, then this will cause build failures. > > One plugin example that opens and does not close a URLClassloader is the > [maven-pmd-plugin|#L796]]. As you can see it calls the method to prepend the > classpath for the plugin to run. This method then [creates|#L196]] a > URLClassloader that is not closed and must be finalized. > > With the deprecation of the finalizer and the knowledge that it is not a good > mechanism for closing system resources reliably, this also causes issues for > larger projects with a lot of modules and a slightly larger build time. > > I am not sure what can be done about this issue in the maven lifecycle, but > just wanted to ask the question and find out if anyone else has seen similar > issues or knows of a way to resolve this open file handles problem. And > possibly find a way to limit the number of open file handles to the > downloaded artifacts. > > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-239) upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build
[ https://issues.apache.org/jira/browse/MPOM-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029240#comment-17029240 ] Hudson commented on MPOM-239: - Build succeeded in Jenkins: Maven TLP » maven-parent » master #43 See https://builds.apache.org/job/maven-box/job/maven-parent/job/master/43/ > upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build > > > Key: MPOM-239 > URL: https://issues.apache.org/jira/browse/MPOM-239 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > > to benefit from https://github.com/codehaus-plexus/plexus-containers/issues/27 > = sort components when merging discovered components with hand-provided > components -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DOXIA-601) Make Doxia build Reproducible
[ https://issues.apache.org/jira/browse/DOXIA-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIA-601. --- Resolution: Fixed done in https://github.com/apache/maven-doxia/commit/bedca8353e18cb6e345501476e70c9181c65a318 > Make Doxia build Reproducible > - > > Key: DOXIA-601 > URL: https://issues.apache.org/jira/browse/DOXIA-601 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 1.9 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 1.9.1 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029239#comment-17029239
]
Karl Heinz Marbaise commented on MNG-6843:
--
An example project is the right way to go that we are able to reproduce the
situation
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
> -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root cause is that
> org.apache.maven.project.MavenProject.setArtifactFilter() is called with null
> artifactFilter parameter. The call happens for the failing module from a
> thread that is building another module. The call stack is:
> {code:java}
> "BuilderThread 0@2513" prio=5 tid=0xe nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.project.MavenProject.setArtifactFilter(MavenProject.java:1437)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:279)
> at
> org.apache.maven.life
[jira] [Commented] (MNG-6848) Ci Friendly builds broke with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029236#comment-17029236
]
Karl Heinz Marbaise commented on MNG-6848:
--
Maybe I misunderstand a thing here but using a property {{version}} instead of
the ones which are supported {{revision}},{{sha1}} and {{changelist}} is simply
not supported by ci friendly
> Ci Friendly builds broke with 3.6.2
> ---
>
> Key: MNG-6848
> URL: https://issues.apache.org/jira/browse/MNG-6848
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Patrick Barry
>Priority: Major
>
> We currently use ci friendly versions introduced in 3.5.0
> [https://maven.apache.org/docs/3.5.0/release-notes.html] Using of CI friendly
> versions via ${revision}, ${sha1} and/or ${changelist} has been fixed
> MNG-6057, MNG-6090 and MNG-5895. It is very important to know if you are
> using the previously named properties for a version in your pom you have to
> use flatten-maven-plugin if you like to do an mvn install or mvn deploy more
> details can be found at Maven CI Friendly Versions.
>
> Our parent pom are defined with the following version attributes:
> {code:java}
> ${version}${revision}
> pom
> com.group
> my-proj
>
>0.0.1
>-SNAPSHOT
>
> {code}
> and then on our build machine, we mvn install -Drevision=
> our sub-modules inherit the version from parent like this:
> {code:java}
>
> com.group
> my-proj
>
> ${version}${revision}
> ..
>
> {code}
> This allows us to only have to define the version in one spot and all
> sub-modules will stay in sync with parent.
> This generated a warning but still worked until 3.6.2
> {noformat}
> 15:56:14 [WARNING] Some problems were encountered while building the
> effective model for com.group:little-proj:jar:2.0.0.48015:56:14 [WARNING]
> 'version' contains an expression but should be a constant. @
> com.group:my-proj:${version}${revision},
> /var/build/workspace/project/pom.xml, line 17, column 14{noformat}
> is now...
> {noformat}
> 15:54:12 [ERROR] 'dependencies.dependency.version' for
> com.group:little-proj:jar is missing. @
> com.group:test-proj:${version}${revision},
> /var/build/workspace/test/./test-proj/pom.xml, line 89, column 22{noformat}
> we use flatten plugin
> {code:java}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.1.0
>
>
> flatten
> process-resources
>
> flatten
>
>
> true
> resolveCiFriendliesOnly
>
>
>
> flatten.clean
> clean
>
> clean
>
>
>
>
> true
> resolveCiFriendliesOnly
>
> {code}
> If this is not the proper way to use Ci-Friendly versions, what is?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"
[ https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029235#comment-17029235 ] Hudson commented on MSHADE-339: --- Build succeeded in Jenkins: Maven TLP » maven-shade-plugin » master #52 See https://builds.apache.org/job/maven-box/job/maven-shade-plugin/job/master/52/ > Shaded test jar has wrong type "jar" > > > Key: MSHADE-339 > URL: https://issues.apache.org/jira/browse/MSHADE-339 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2, 3.2.2 >Reporter: Peter De Maeyer >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.2 > > Time Spent: 20m > Remaining Estimate: 0h > > The shaded test jar has the wrong type "jar". > It should be "test-jar". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-674) maven-dependency-plugin:copy goal should define m2e metadata
[ https://issues.apache.org/jira/browse/MDEP-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029233#comment-17029233 ] Karl Heinz Marbaise commented on MDEP-674: -- Can you please share project examples cause in general I would say it's bad idea to use dependency plugin for packaging there are other plugins like maven-assembly-plugin etc. better choice but it depends on the use case? > maven-dependency-plugin:copy goal should define m2e metadata > > > Key: MDEP-674 > URL: https://issues.apache.org/jira/browse/MDEP-674 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: copy >Reporter: Mickael Istria >Priority: Minor > > I often use the maven-dependency-plugon:copy goal for packaging purpose. > However, Eclipse m2e complains that "plugin execution isn't covered...". > This could be improved by adding just m2e lifecycle mapping metadata and > leveraging the BuildContext API: > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-674) maven-dependency-plugin:copy goal should define m2e metadata
[ https://issues.apache.org/jira/browse/MDEP-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MDEP-674: - Component/s: copy > maven-dependency-plugin:copy goal should define m2e metadata > > > Key: MDEP-674 > URL: https://issues.apache.org/jira/browse/MDEP-674 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: copy >Reporter: Mickael Istria >Priority: Minor > > I often use the maven-dependency-plugon:copy goal for packaging purpose. > However, Eclipse m2e complains that "plugin execution isn't covered...". > This could be improved by adding just m2e lifecycle mapping metadata and > leveraging the BuildContext API: > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (MDEP-674) maven-dependency-plugin:copy goal should define m2e metadata
[ https://issues.apache.org/jira/browse/MDEP-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise moved MNG-6849 to MDEP-674: --- Component/s: (was: Dependencies) Key: MDEP-674 (was: MNG-6849) Project: Maven Dependency Plugin (was: Maven) > maven-dependency-plugin:copy goal should define m2e metadata > > > Key: MDEP-674 > URL: https://issues.apache.org/jira/browse/MDEP-674 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: Mickael Istria >Priority: Minor > > I often use the maven-dependency-plugon:copy goal for packaging purpose. > However, Eclipse m2e complains that "plugin execution isn't covered...". > This could be improved by adding just m2e lifecycle mapping metadata and > leveraging the BuildContext API: > https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6858) Need a way to skip empty-string arguments
[
https://issues.apache.org/jira/browse/MNG-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029229#comment-17029229
]
Karl Heinz Marbaise commented on MNG-6858:
--
[~Pr0methean] The command you have given will executed the compile life cycle
two times cause you are using the life cycle {{compile}} after {{clean}} and
furthermore using {{test}} life cycle after the {{jacoco:prepare-agent}}. In
the end this will result in compiling two times.
> Need a way to skip empty-string arguments
> -
>
> Key: MNG-6858
> URL: https://issues.apache.org/jira/browse/MNG-6858
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.1
> Environment: Ubuntu 19.10
>Reporter: Chris Hennick
>Priority: Major
>
> I have a bash script that sets a sometimes-empty variable as follows:
>
> {code:java}
> if [ "${ANDROID}" = "true" ]; then
> MAYBE_ANDROID_FLAG=-Pandroid
> else
> MAYBE_ANDROID_FLAG=
> fi{code}
>
> It's used like so:
>
> {code:java}
> mvn ${MAYBE_ANDROID_FLAG} clean compile jacoco:instrument
> jacoco:prepare-agent test jacoco:restore-instrumented-classes jacoco:report
> -e -B}}{code}
>
> Shell-scripting best practices dictate that ${MAYBE_ANDROID_FLAG} above
> should be in double quotes, but when I do that, I get 'Unknown lifecycle
> phase ""'. For it to be possible to follow best practices, then, we need a
> way to make Maven skip over command-line arguments that are empty strings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029212#comment-17029212
]
Albert Johnston commented on SUREFIRE-1748:
---
I hadn't tested against it recently, though I did try that when I first
discovered it. Anyways, I updated the repo to target the snapshot. Issue still
exists.
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1217)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1063)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:889){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029207#comment-17029207 ] Michael Osipov commented on MNG-6789: - Agree, but that would depict when the release has been rolled and has not been changed compared to Git. > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap & Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MINSTALL-167) Upgrade parent to version 34
[ https://issues.apache.org/jira/browse/MINSTALL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MINSTALL-167: Assignee: Karl Heinz Marbaise > Upgrade parent to version 34 > > > Key: MINSTALL-167 > URL: https://issues.apache.org/jira/browse/MINSTALL-167 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINSTALL-167) Upgrade parent to version 34
Karl Heinz Marbaise created MINSTALL-167: Summary: Upgrade parent to version 34 Key: MINSTALL-167 URL: https://issues.apache.org/jira/browse/MINSTALL-167 Project: Maven Install Plugin Issue Type: Dependency upgrade Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MPOM-239) upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build
[ https://issues.apache.org/jira/browse/MPOM-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPOM-239. -- Resolution: Fixed done in https://github.com/apache/maven-parent/commit/bbbf1dde405e6ad1f12ce630146c9a59dc3c2742 > upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build > > > Key: MPOM-239 > URL: https://issues.apache.org/jira/browse/MPOM-239 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Affects Versions: MAVEN-34 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: MAVEN-35 > > > to benefit from https://github.com/codehaus-plexus/plexus-containers/issues/27 > = sort components when merging discovered components with hand-provided > components -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MPOM-239) upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build
Herve Boutemy created MPOM-239: -- Summary: upgrade plexus-component-metadata to 2.1.0 for better Reproducible Build Key: MPOM-239 URL: https://issues.apache.org/jira/browse/MPOM-239 Project: Maven POMs Issue Type: Dependency upgrade Components: maven Affects Versions: MAVEN-34 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: MAVEN-35 to benefit from https://github.com/codehaus-plexus/plexus-containers/issues/27 = sort components when merging discovered components with hand-provided components -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-346) Introduce mock repository manager for testing
[ https://issues.apache.org/jira/browse/MSHADE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHADE-346. - Resolution: Fixed Fixed in [52c476a9acf8c9af03d04a29f33ced905906275c|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commit;h=52c476a9acf8c9af03d04a29f33ced905906275c] > Introduce mock repository manager for testing > - > > Key: MSHADE-346 > URL: https://issues.apache.org/jira/browse/MSHADE-346 > Project: Maven Shade Plugin > Issue Type: Task >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.2.2 > > > The mock repository manager removes the need for jars in the sourcecode. > This way it will be clear which content is tested. > It will also remove the bad practice of repositories in poms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6789) Make Maven distribution build Reproducible
[ https://issues.apache.org/jira/browse/MNG-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029160#comment-17029160 ] Herve Boutemy commented on MNG-6789: at least, it does not break reproducibility: I'm not against from this point of view is it worth to do it? I really don't know. Thinking at it, I prefer to not have a "timestamp" property in build.properties that does not really represent the timestamp of the build: now that we have reproducible build, the timestamp of the build is something a notion that does not have any interest since we get the same result whenever the effective build is done > Make Maven distribution build Reproducible > -- > > Key: MNG-6789 > URL: https://issues.apache.org/jira/browse/MNG-6789 > Project: Maven > Issue Type: Task > Components: Bootstrap & Build >Affects Versions: 3.6.2 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.3 > > > with [Maven native Reproducible > Builds|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318] > near available, it would be great to have Maven itself being the first Maven > project that gets Reproducible Builds > there is already a proof of concept available in reproducible branch: > https://github.com/apache/maven/tree/reproducible with corresponding Jenkins > build > https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/reproducible/ > once maven-jar-plugin, maven-assembly-plugin and maven-source-plugin have a > reproducible release available, the last 2 plugins that bring non > reproducible result in this build are plexus-component-metadata 2.0.0 and > sisu-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-339) Shaded test jar has wrong type "jar"
[ https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHADE-339. Resolution: Fixed merged the updated PR content, ie not the old content that was in MSHADE-339 branch https://github.com/apache/maven-shade-plugin/commit/85509b1574663be0856ab8e8eca303aa17445011 > Shaded test jar has wrong type "jar" > > > Key: MSHADE-339 > URL: https://issues.apache.org/jira/browse/MSHADE-339 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2, 3.2.2 >Reporter: Peter De Maeyer >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.2.2 > > Time Spent: 20m > Remaining Estimate: 0h > > The shaded test jar has the wrong type "jar". > It should be "test-jar". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shade-plugin] hboutemy commented on issue #33: [MSHADE-339] - Shaded test jar has wrong type "jar"
hboutemy commented on issue #33: [MSHADE-339] - Shaded test jar has wrong type "jar" URL: https://github.com/apache/maven-shade-plugin/pull/33#issuecomment-581542628 merged with rebase and commit log rewrite in 85509b1574663be0856ab8e8eca303aa17445011 thank you Peter for the harder than expected work :) This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [maven-shade-plugin] hboutemy closed pull request #33: [MSHADE-339] - Shaded test jar has wrong type "jar"
hboutemy closed pull request #33: [MSHADE-339] - Shaded test jar has wrong type "jar" URL: https://github.com/apache/maven-shade-plugin/pull/33 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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-681) Add timestamp when each test is run in the generated report
[
https://issues.apache.org/jira/browse/SUREFIRE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029048#comment-17029048
]
finn desolace commented on SUREFIRE-681:
[~tibordigana] I'm looking for this feature also. Not familier with PR and
code implementation to do so myself.
> Add timestamp when each test is run in the generated report
> ---
>
> Key: SUREFIRE-681
> URL: https://issues.apache.org/jira/browse/SUREFIRE-681
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Viggo Navarsete
>Priority: Major
> Fix For: Backlog
>
>
> We run integration tests using maven-surefire-plugin by filtering on the
> names (they end with *TestIntegration). These tests access a JBoss server,
> and leave log entires in the server log. When a test fail, it would be great
> to have a timestamp on each test in the test report from surefire so that it
> can be matched against what is happening in the server log. This is
> especially true when you have a lot of integration tests running and you
> can't directly spot the server log entries related to the failing test. By
> adding a timestamp to the tests it would make it MUCH easier to figure out
> the server log dependent calls.
> Current output:
> {noformat}
> ---
> Test set: com.tracetracker.gqi3.QueryRestTestIntegration
> ---
> Tests run: 17, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.546 sec
> <<< FAILURE!
> testSimpleEventQueryRecordTime(com.tracetracker.gqi3.QueryRestTestIntegration)
> Time elapsed: 0.031 sec <<< FAILURE!
> junit.framework.AssertionFailedError: List of recordTime should not be empty
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> com.tracetracker.gqi3.QueryRestTestIntegration.testSimpleEventQueryRecordTime(QueryRestTestIntegration.java:283)
> {noformat}
> Each failing test should have the timestamp added to the start of the line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17029000#comment-17029000
]
Tibor Digana commented on SUREFIRE-1748:
Have you used the SNAPSHOT version as well?
> JUnit 5 Assertions.fail() breaks reporting
> --
>
> Key: SUREFIRE-1748
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
> * JUnit Jupiter 5.3.2
> * JDK 1.8u172
> * Maven 3.6.3
> Demonstration available at
> [https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
> If the following JUnit 5 code is run through Surefire, then the reporting
> breaks for that class, resulting in no reported errors/failures from that
> class (though any failures will still be reported overall in the counts):
> {code:java}
> public class JUnit5Test {
> @Test
> void failWithNoParameters() {
> Assertions.fail();
> }
> }
> {code}
> Resulting output:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace...{noformat}
> And with the -e flag, trimmed to the relevant part:
>
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016
> s <<< FAILURE! - in JUnit5Test
> [ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
> [ERROR] Failures:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test)
> on project junit-assertions-fail: Execution default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test
> (default-test) on project junit-assertions-fail: Execution default-test of
> goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
> (DefaultReporterFactory.java:398)
> at
> org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
> (DefaultReporterFactory.java:198)
> at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
> (DefaultReporterFactory.java:171)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
> (ForkStarter.java:254)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
> (AbstractSurefireMojo.java:1217)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
> (AbstractSurefireMojo.java:1063)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
> (AbstractSurefireMojo.java:889){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-347) Reproducible Builds: make entries in output jar files reproducible
[ https://issues.apache.org/jira/browse/MSHADE-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy resolved MSHADE-347. -- Resolution: Fixed done in https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git&a=commit&h=069c7c9b480532d81d3c926779c000b5f511bc09 > Reproducible Builds: make entries in output jar files reproducible > -- > > Key: MSHADE-347 > URL: https://issues.apache.org/jira/browse/MSHADE-347 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.2.2 > > > since a jar file is a zip file, entries order and timestamp are a natural > source of non Reproducible Builds: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 > need to keep timestamp of input zip entries into output -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCOMPILER-408) CompileMojo resets project artifacts when used in verify phase
Benjamin Marwell created MCOMPILER-408:
--
Summary: CompileMojo resets project artifacts when used in verify
phase
Key: MCOMPILER-408
URL: https://issues.apache.org/jira/browse/MCOMPILER-408
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.8.1, 3.8.0
Environment: - Maven 3.6.2
- Maven compiler plugin
- errorprone
Reporter: Benjamin Marwell
h2. Problem Description / Setup
I tried to execute the google error-prone plugin in the compile phase, but was
unsatisfied with the outcome. However, it seemed to be a perfect fit for the
{{verify}} phase. Other plugins will also use the verify phase, e.g.
checkstyle. I will also compile it to a different folder (which is
{{target/classes-errorprone}}).
However, when using the CompileMojo, it will always call
[projectArtifact.setFile(dir);|[https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L189]].
There is no possibility to override this.
I do think this is not always the wanted behaviour.
Now, when executing
{code:java}
mvn clean verify -Perrorprone {code}
the {{ear}} project will not find the {{war}} anymore, because the war had:
* Compile phase creating target/classes
* package phase, which set projectArtifact.setFile() to the {{.war}} file.
* verify phase, which set projectArtifact.setFile() back to {{target/classes}}.
h2. Reproducible
Always, see above.
h2. Workarounds
Do not execute verify+errorprone together with your main target phase and all
reactor projects (e.g. including ear). But this will need two compile steps
(one for packaging, anothero ne for error-prone).
h2. Expected behaviour
I can execute the maven-compiler-plugin with a compiler plugin like checkstyle
in the verify phase without un-attaching any previous artifacts. At least as
long as I compile into another directory.
h2. Actual behaviour
I cannot execute the compiler in the verify phase again using the
{{maven-compiler-plugin}}, because it will reset my project artifacts.
h2. errorprone configuration
{code:java}
errorprone
false
maven-compiler-plugin
errorprone
verify
compile
true
-XDcompilePolicy=simple
-Xplugin:ErrorProne
${plugin.errorprone.excluded.paths}
-XepDisableWarningsInGeneratedCode
${plugin.errorprone.additional.checks}
-d
${project.build.directory}/classes-ep
com.google.errorprone
error_prone_core
${dependency.errorprone.core.version}
true
{code}
Note: I use incrementalCompilation=true which behaves like non-incremental
compilation due to a bug which is open since ever.
h2. Proposed sulutions
Either create a new goal (compile-only) or provide a switch to not invoke
[projectArtifact.setFile(outputdir)|[https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L189]].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] ajohnstonTE edited a comment on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers
ajohnstonTE edited a comment on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers URL: https://github.com/apache/maven-surefire/pull/267#issuecomment-581331763 Well, I've been trying to look into another issue I noticed while working on this one, but I haven't really gotten anywhere with it. TL;DR: Using JUnit 5's `Assertions.fail()` method with no arguments or an empty string breaks something in Surefire's reporting. Specifically an NPE. I'll open up a ticket for it. This is the issue: https://issues.apache.org/jira/browse/SUREFIRE-1748 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [Updated] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
[
https://issues.apache.org/jira/browse/SUREFIRE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Johnston updated SUREFIRE-1748:
--
Description:
Associated versions on my end at time of testing:
* JUnit Jupiter 5.3.2
* JDK 1.8u172
* Maven 3.6.3
Demonstration available at
[https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
If the following JUnit 5 code is run through Surefire, then the reporting
breaks for that class, resulting in no reported errors/failures from that class
(though any failures will still be reported overall in the counts):
{code:java}
public class JUnit5Test {
@Test
void failWithNoParameters() {
Assertions.fail();
}
}
{code}
Resulting output:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace...{noformat}
And with the -e flag, trimmed to the relevant part:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
(DefaultReporterFactory.java:398)
at
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
(DefaultReporterFactory.java:198)
at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
(DefaultReporterFactory.java:171)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
(ForkStarter.java:254)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
(AbstractSurefireMojo.java:1217)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
(AbstractSurefireMojo.java:1063)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
(AbstractSurefireMojo.java:889){noformat}
was:
Associated versions on my end at time of testing:
* JUnit Jupiter 5.3.2
* JDK 1.8u172
* Maven 3.6.3
Demonstration available at
[https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
If the following JUnit 5 code is run through Surefire, then the reporting
breaks for that class, resulting in no reported errors/failures from that class
(though any failures will still be reported overall in the counts):
public class JUnit5Test {
@Test
void failWithNoParameters() {
Assertions.fail();
}
}
Resulting output:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace...{noformat}
And with the -e flag, trimmed to the relevant part:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:m
[jira] [Created] (SUREFIRE-1748) JUnit 5 Assertions.fail() breaks reporting
Albert Johnston created SUREFIRE-1748:
-
Summary: JUnit 5 Assertions.fail() breaks reporting
Key: SUREFIRE-1748
URL: https://issues.apache.org/jira/browse/SUREFIRE-1748
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin
Affects Versions: 3.0.0-M4
Reporter: Albert Johnston
Associated versions on my end at time of testing:
* JUnit Jupiter 5.3.2
* JDK 1.8u172
* Maven 3.6.3
Demonstration available at
[https://github.com/ajohnstonTE/surefire-jira-examples/tree/master/junit-assertions-fail]
If the following JUnit 5 code is run through Surefire, then the reporting
breaks for that class, resulting in no reported errors/failures from that class
(though any failures will still be reported overall in the counts):
public class JUnit5Test {
@Test
void failWithNoParameters() {
Assertions.fail();
}
}
Resulting output:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.008 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace...{noformat}
And with the -e flag, trimmed to the relevant part:
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 s
<<< FAILURE! - in JUnit5Test
[ERROR] JUnit5Test.failWithNoParameters Time elapsed: 0.007 s <<< FAILURE!
[ERROR] Failures:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.:
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-test) on
project junit-assertions-fail: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed.
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.printTestFailures
(DefaultReporterFactory.java:398)
at
org.apache.maven.plugin.surefire.report.DefaultReporterFactory.runCompleted
(DefaultReporterFactory.java:198)
at org.apache.maven.plugin.surefire.report.DefaultReporterFactory.close
(DefaultReporterFactory.java:171)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run
(ForkStarter.java:254)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider
(AbstractSurefireMojo.java:1217)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
(AbstractSurefireMojo.java:1063)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute
(AbstractSurefireMojo.java:889){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] ajohnstonTE commented on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers
ajohnstonTE commented on issue #267: [SUREFIRE-1741] JUnit5: Detect failed containers URL: https://github.com/apache/maven-surefire/pull/267#issuecomment-581331763 Well, I've been trying to look into another issue I noticed while working on this one, but I haven't really gotten anywhere with it. TL;DR: Using JUnit 5's `Assertions.fail()` method with no arguments or an empty string breaks something in Surefire's reporting. Specifically an NPE. I'll open up a ticket for it. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
