[GitHub] [maven-jarsigner-plugin] martinmikula commented on issue #2: Mark verify and sign Mojos thread safe
martinmikula commented on issue #2: Mark verify and sign Mojos thread safe URL: https://github.com/apache/maven-jarsigner-plugin/pull/2#issuecomment-535216174 It would be really nice, I hate the warnings... 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] (MSHADE-251) Add skip parameter to shade goal
[ https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938053#comment-16938053 ] Jonathan Haber commented on MSHADE-251: --- I pushed an example project to GitHub here: [https://github.com/jhaber/MSHADE-251] If you want to play with it, you can clone it and run "mvn clean verify" from the root directory. At the top level there are two folders. The first folder is called packaging-plugin; this folder contains a Maven plugin which would be owned by our infrastructure team. The second folder is called example-project. For simplicity I just embedded the plugin configuration directly in its POM, but in reality all of this plugin configuration would be centralized in our parent POM that our applications extend: [https://github.com/jhaber/MSHADE-251/blob/c534a3a31fef9dd4d9369c1bd1f1281ed5baee29/example-project/pom.xml#L23-L147] There you can see the executable profile activated by a .build-executable file: [https://github.com/jhaber/MSHADE-251/blob/c534a3a31fef9dd4d9369c1bd1f1281ed5baee29/example-project/pom.xml#L47-L52] This profile triggers the packaging-plugin to run, it also modifies some configuration on the JAR plugin, and finally it runs 3 separate packaging plugins. There is the shade plugin which builds a fat JAR, the slimfast plugin upload goal (uploads dependencies to S3), and the slimfast plugin copy goal (copies dependencies to target folder). We only want to actually execute one of these 3 goals. The job of the packaging-plugin is to inspect the currently building module, determine which packaging mode is appropriate, and set the corresponding Maven properties so that the desired plugin executes and the others get skipped. For example, it sets these properties if packaging as a fat JAR is desired: [https://github.com/jhaber/MSHADE-251/blob/c534a3a31fef9dd4d9369c1bd1f1281ed5baee29/packaging-plugin/src/main/java/com/packaging/ConfigurePackagingMojo.java#L44-L48] It determines which packaging mode to use based on the type of the deployable being built, which is set as a Maven property, as well as the environment that the build is happening in (for example, we only want to upload dependencies to S3 when building inside our CI environment). Similarly, maybe we package Spark jobs and Lambda functions as fat JARs for convenience: [https://github.com/jhaber/MSHADE-251/blob/c534a3a31fef9dd4d9369c1bd1f1281ed5baee29/packaging-plugin/src/main/java/com/packaging/ConfigurePackagingMojo.java#L14-L16] But other deployable types can use a more efficient packaging mode. These deployable types are set as properties in the POM, which can't be used to influence profile activation: [https://github.com/jhaber/MSHADE-251/blob/c534a3a31fef9dd4d9369c1bd1f1281ed5baee29/example-project/example-rest-api/pom.xml#L15] And crucially, as a user of this system you don't have to worry about any of these details. You just say that you're building a spark job and the infrastructure handles packaging that appropriately. For example, maybe the infrastructure team implements some optimization so that we no longer need to build fat JARs for Spark. With this setup, no user code needs to get updated. We would only need to update the logic in the packaging plugin, which is also owned by the infrastructure team. In reality this is all at a much larger scale and more complex, but hopefully this example is helpful > Add skip parameter to shade goal > > > Key: MSHADE-251 > URL: https://issues.apache.org/jira/browse/MSHADE-251 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Jonathan Haber >Priority: Minor > > Most Maven plugins have a skip parameter but not the shade plugin. Our > use-case is that we have multiple ways of packaging apps for deployment > (using the shade plugin is one such way). We have these packaging plugins > defined in our shared parent POM and projects can use Maven properties to > control which ones to skip and which to execute. > We've added this feature on our fork (which you can view > [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]). > It's not much code and having a skip parameter can be a lifesaver when you > need it, so I was hoping this feature could get added. Let me know what you > think. > Thanks, > Jonathan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSITE-847) "$prerequisiteMavenVersion" text in plugin's documentation
[
https://issues.apache.org/jira/browse/MSITE-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937667#comment-16937667
]
Kathryn Newbould commented on MSITE-847:
Yes, Robert, that worked!
> "$prerequisiteMavenVersion" text in plugin's documentation
> --
>
> Key: MSITE-847
> URL: https://issues.apache.org/jira/browse/MSITE-847
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: documentation
>Affects Versions: 3.8.2
>Reporter: Hervé Boutemy
>Priority: Trivial
> Labels: up-for-grabs
>
> looking at https://maven.apache.org/plugins-archives/maven-site-plugin-3.8.2/
> {quote}It requires at least Maven $prerequisiteMavenVersion to run{quote}
> where previously we had
> https://maven.apache.org/plugins-archives/maven-site-plugin-3.7.1/
> {quote}It requires at least Maven 2.2.1 to run{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-release] msymons edited a comment on issue #29: [MRELEASE-229] Implementation of RemoveScmTagPhase; updated maven-scm
msymons edited a comment on issue #29: [MRELEASE-229] Implementation of RemoveScmTagPhase; updated maven-scm URL: https://github.com/apache/maven-release/pull/29#issuecomment-534964086 @michael-o, is this PR now reviewable/mergable? The failure to remove tags on rollback causes a lot of problems in our pipelines... it would be great if this could be addressed for upcoming Maven Release Plugin v3.0.0 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-release] msymons commented on issue #29: [MRELEASE-229] Implementation of RemoveScmTagPhase; updated maven-scm
msymons commented on issue #29: [MRELEASE-229] Implementation of RemoveScmTagPhase; updated maven-scm URL: https://github.com/apache/maven-release/pull/29#issuecomment-534964086 @michael-o, is this PR noew reviewable/mergable? The failure to remove tags on rollback causes a lot of problems in our pipelines... it would be great if this could be addressed for upcoming Maven Release Plugin v3.0.0 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] (MDEPLOY-246) Deploy doesn't send authentication credentials
[
https://issues.apache.org/jira/browse/MDEPLOY-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937609#comment-16937609
]
Mirko Friedenhagen commented on MDEPLOY-246:
As a hacky workaround, at least with 3.0.0-M1 you may define an additional
{{server}} with {{id}} like {{central::default}}, i.e. {{REPO_ID::default}} in
your {{settings.xml}}.
> Deploy doesn't send authentication credentials
> --
>
> Key: MDEPLOY-246
> URL: https://issues.apache.org/jira/browse/MDEPLOY-246
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Daniel Duarte Simões
>Priority: Major
>
> Regression.
> Plugin doesn't send "Authorization" header during HTTP Put.
>
> Information:
> * credentials configured in settings.xml
> * basic authentication
> * works in version <= 2.8.2
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-251) Add skip parameter to shade goal
[
https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937553#comment-16937553
]
Björn Michael commented on MSHADE-251:
--
The best known example originates from Maven Surefire Plugin providing
[skipTests|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skipTests]
User property. IMO a new skip parameter would increase flexibilty a lot and
would outweigh codesmell concerns.
E.g. it would allow to skip the execution of an existing shade plugin
definition within a project without touching {{pom.xml}} at command line.
My usecase - usage of _skip_ parameter in core / common module
# Parent project contains a _build-fat_ profile containing shade plugin
definition.
# Reactor comprises of 12 modules each has one Main class and 1 core / common
module without a Main class i.e. should not use shade plugin.
# Build whole reactor with -Pbuild-fat but exclude this profile for core module
A simple _skip_ parameter in core / common module would be completely
sufficient.
> Add skip parameter to shade goal
>
>
> Key: MSHADE-251
> URL: https://issues.apache.org/jira/browse/MSHADE-251
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Jonathan Haber
>Priority: Minor
>
> Most Maven plugins have a skip parameter but not the shade plugin. Our
> use-case is that we have multiple ways of packaging apps for deployment
> (using the shade plugin is one such way). We have these packaging plugins
> defined in our shared parent POM and projects can use Maven properties to
> control which ones to skip and which to execute.
> We've added this feature on our fork (which you can view
> [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]).
> It's not much code and having a skip parameter can be a lifesaver when you
> need it, so I was hoping this feature could get added. Let me know what you
> think.
> Thanks,
> Jonathan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCOMPILER-400) Explicit way to disable toolchain for compiler and use in-process compiler
Tuure Laurinolli created MCOMPILER-400: -- Summary: Explicit way to disable toolchain for compiler and use in-process compiler Key: MCOMPILER-400 URL: https://issues.apache.org/jira/browse/MCOMPILER-400 Project: Maven Compiler Plugin Issue Type: Wish Affects Versions: 3.8.1 Reporter: Tuure Laurinolli We use toolchains configured with the Maven Toolchains plugin to run tests on both JDK 8 and JDK 11. We still only compile on JDK 8, and the JVM runnin Maven is 8. We want to avoid forking a new JVM per-compilation because it more than doubles the basic build & run unit tests time for out project from 200 to 450 seconds since our module structure is fairly granular. By looking at the source code of Maven Compiler plugin, we figured out that setting *fork* to false and *executable* to whatever we can avoid using a toolchain in the compiler plugin. However, this seems rather hackish, and we would like to see a solution that's morelikely to stay supported in the future as well. Some options that come to mind: 1) Don't use toolchain if *fork* is disabled, regardless of *executable* value. The upside is that this is arguably what should happen anyway. Why would we want to fork in the presence of a toolchain if fork is set to false? 2) Add a specific flag to disable toolchain usage in the compiler plugin, regardless of other flags. Better than 1) in that current configurations retain their current semantics, but seems a bit odd. 3) Document the current state of things as the supported way to achieve compilation-in-process-even-if-toolchain-is-configured. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated MASSEMBLY-919:
-
Priority: Blocker (was: Major)
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.1
>Reporter: Zsombor Gegesy
>Priority: Blocker
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsombor Gegesy updated MASSEMBLY-919:
-
Flags: Patch
Labels: patch-available (was: )
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.1
>Reporter: Zsombor Gegesy
>Priority: Major
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MASSEMBLY-919) Transitive dependency of a test dependency is included
[
https://issues.apache.org/jira/browse/MASSEMBLY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937481#comment-16937481
]
Zsombor Gegesy commented on MASSEMBLY-919:
--
Any comment on the proposed patch?
> Transitive dependency of a test dependency is included
> --
>
> Key: MASSEMBLY-919
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-919
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.1.1
>Reporter: Zsombor Gegesy
>Priority: Major
> Labels: patch-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have a simple module, with one compile 'module-a' dependency, and with one
> test dependency ('module-b'), which has a couple of 'compile' dependencies
> (module-b-1, module-b-2, etc)
> In my assembly.xml I have:
> {code:java}
>
>
> true
> tools
> false
>
> runtime
> true
>
>
> {code}
> I would assume, that in this case, only 'module-a.jar' ends in the tool
> folder, however, the plugin adds module-b-1, module-b-2, etc too - which is
> not expected, as they are dependencies of 'module-b', which has test scope
> only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-compiler-plugin] rhowe opened a new pull request #25: [MCOMPILER-399] Upgrade mockito from 1.9.5 to 2.28.2
rhowe opened a new pull request #25: [MCOMPILER-399] Upgrade mockito from 1.9.5 to 2.28.2 URL: https://github.com/apache/maven-compiler-plugin/pull/25 This builds alright for me (admittedly, on Java 11) Mockito 2.x still supports Java 6, however, so I think this is OK? - [x ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) 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] (MCOMPILER-399) Upgrade mockito to latest 2.x
[ https://issues.apache.org/jira/browse/MCOMPILER-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Howe updated MCOMPILER-399: --- Priority: Trivial (was: Major) > Upgrade mockito to latest 2.x > - > > Key: MCOMPILER-399 > URL: https://issues.apache.org/jira/browse/MCOMPILER-399 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Russell Howe >Priority: Trivial > > Currently the build uses mockito 1.9.5 from October 2012. > We ought to be able to use at least the latest 2.x release (3.x requires Java > 8) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MCOMPILER-399) Upgrade mockito to latest 2.x
Russell Howe created MCOMPILER-399: -- Summary: Upgrade mockito to latest 2.x Key: MCOMPILER-399 URL: https://issues.apache.org/jira/browse/MCOMPILER-399 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Reporter: Russell Howe Currently the build uses mockito 1.9.5 from October 2012. We ought to be able to use at least the latest 2.x release (3.x requires Java 8) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695 Support multiple inheritance of @Categories
IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695
Support multiple inheritance of @Categories
URL: https://github.com/apache/maven-surefire/pull/248#discussion_r327954765
##
File path:
surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/GroupMatcherCategoryFilter.java
##
@@ -63,33 +63,50 @@
@Override
public boolean shouldRun( Description description )
{
-if ( description.getMethodName() == null || description.getTestClass()
== null )
-{
+if(invalidTestClass(description)){
return shouldRun( description, null, null );
}
-else
+
+if (describesTestClass(description)) // is a test class
+{
+Class testClass = description.getTestClass();
+return shouldRun( description, null, testClass );
+}
+else // is a test method
{
Class testClass = description.getTestClass();
return shouldRun( description, createSuiteDescription( testClass
), testClass );
}
}
+private boolean describesTestClass(Description description) {
+// Description parser in Junit 4.8 can return "null" String.
+return description.getMethodName() == null ||
description.getMethodName().equals("null");
+}
+
+private boolean invalidTestClass(Description description) {
+return description.getTestClass() == null;
+}
+
private static void findSuperclassCategories( Set> cats, Class
clazz )
{
-if ( clazz != null && clazz.getSuperclass() != null )
+if (hasSuperclass(clazz))
{
Category cat = clazz.getSuperclass().getAnnotation( Category.class
);
if ( cat != null )
{
+// Found categories in current superclass
addAll( cats, cat.value() );
}
-else
-{
-findSuperclassCategories( cats, clazz.getSuperclass() );
-}
+// Search the hierarchy
+findSuperclassCategories( cats, clazz.getSuperclass() );
Review comment:
Hi, thanks for the Review! However, I don't understand this comment. Do you
mean that a @Category in a subclass should override (i.e. replace) the classes
in the @Category from the superclass? Because this is exactly the opposite of
what I implemented. I expect that the categories declared in the superclass
are included as categories of the subclass, without needing to re-declare them.
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-surefire] IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695 Support multiple inheritance of @Categories
IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695
Support multiple inheritance of @Categories
URL: https://github.com/apache/maven-surefire/pull/248#discussion_r327955154
##
File path:
surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/GroupMatcherCategoryFilter.java
##
@@ -63,33 +63,50 @@
@Override
public boolean shouldRun( Description description )
{
-if ( description.getMethodName() == null || description.getTestClass()
== null )
-{
+if(invalidTestClass(description)){
Review comment:
yes, I didn't use the Apache formatter. I'll fix 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
[GitHub] [maven-surefire] IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695 Support multiple inheritance of @Categories
IoannisDermitzakis commented on a change in pull request #248: SUREFIRE-1695
Support multiple inheritance of @Categories
URL: https://github.com/apache/maven-surefire/pull/248#discussion_r327954765
##
File path:
surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/GroupMatcherCategoryFilter.java
##
@@ -63,33 +63,50 @@
@Override
public boolean shouldRun( Description description )
{
-if ( description.getMethodName() == null || description.getTestClass()
== null )
-{
+if(invalidTestClass(description)){
return shouldRun( description, null, null );
}
-else
+
+if (describesTestClass(description)) // is a test class
+{
+Class testClass = description.getTestClass();
+return shouldRun( description, null, testClass );
+}
+else // is a test method
{
Class testClass = description.getTestClass();
return shouldRun( description, createSuiteDescription( testClass
), testClass );
}
}
+private boolean describesTestClass(Description description) {
+// Description parser in Junit 4.8 can return "null" String.
+return description.getMethodName() == null ||
description.getMethodName().equals("null");
+}
+
+private boolean invalidTestClass(Description description) {
+return description.getTestClass() == null;
+}
+
private static void findSuperclassCategories( Set> cats, Class
clazz )
{
-if ( clazz != null && clazz.getSuperclass() != null )
+if (hasSuperclass(clazz))
{
Category cat = clazz.getSuperclass().getAnnotation( Category.class
);
if ( cat != null )
{
+// Found categories in current superclass
addAll( cats, cat.value() );
}
-else
-{
-findSuperclassCategories( cats, clazz.getSuperclass() );
-}
+// Search the hierarchy
+findSuperclassCategories( cats, clazz.getSuperclass() );
Review comment:
Hi, thanks for the Review! However, I don't understand this comment. Do you
mean that a @Category in a subclass should override (i.e. replace) the classes
in the @Category from the superclass? Because this is exactly the opposite of
what I implemented. I expect that the classes in the superclass are included
as categories of the subclass, without needing to re-declare them.
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-1688) Junit Platform test with failing @BeforeAll does not fail the build
[
https://issues.apache.org/jira/browse/SUREFIRE-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937436#comment-16937436
]
Guy Brand commented on SUREFIRE-1688:
-
With a newer snapshot after the one I tested while reporting the issue was not
present anymore. Could you close it as explained? Thanks.
> Junit Platform test with failing @BeforeAll does not fail the build
> ---
>
> Key: SUREFIRE-1688
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1688
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Reporter: Guy Brand
>Priority: Major
>
> When using Surefire {{3.0.0-SNAPSHOT}} and JUnit Platform {{5.4.2}} the
> following test does not fail the Maven build.
> {code:java}
> import org.junit.jupiter.api.Test;
> import org.junit.jupiter.api.BeforeAll;
> import org.junit.jupiter.api.Assertions;
> public class Tests {
> @BeforeAll
> public static void beforeAll() { Assertions.fail("BeforeAll fail"); }
> @Test
> public void test() { Assertions.fail("Test fail"); }
> }
> {code}
> And its output:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @
> top-level-project ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running Tests
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015
> s - in Tests
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> When removing the {{@BeforeAll}} annotation/method it fails as expected.
> {{3.0.0-M3}} version of Surefire works as expected:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @
> top-level-project ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running Tests
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.008
> s <<< FAILURE! - in Tests
> [ERROR] Tests Time elapsed: 0.007 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: BeforeAll fail
> at Tests.beforeAll(Tests.java:7)
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] Tests.beforeAll:7 BeforeAll fail
> [INFO]
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.373 s
> [INFO] Finished at: 2019-08-20T16:20:16+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test)
> on project top-level-project: There are test failures.
> {code}
> For all the tests Maven 3.6.1 has been used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
