Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Tibor17 · 2022-03-05T20:04:37Z

The plugin does not have a real problem with the class path as we expected in the Jira issue SUREFIRE-2000.
I found this PR as an improvement where the junit-platform-runner can be in the plugin dependencies. The previous implementation expected junit-platform-runner only in the project dependencies. Additionally, we added junit-platform-suite-engine as a successor of junit-platform-runner in the documentation and IT.

Following this checklist to help us incorporate your
contribution quickly and easily:

Make sure there is a JIRA issue filed
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
Each commit in the pull request should have a meaningful subject line and body.
Format the pull request title like [SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles,
where you replace SUREFIRE-XXX with the appropriate JIRA issue. Best practice
is to use the JIRA issue title in the pull request title and in the first line of the
commit message.
Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
Run mvn clean install to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
You have run the integration tests successfully (mvn -Prun-its clean install).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.

…in dependencies

slawekjaranowski · 2022-03-05T20:32:24Z

surefire-its/src/test/java/org/apache/maven/surefire/its/JUnitPlatformEnginesIT.java

+        //args.add( new Object[] {"1.1.1", "5.1.1", "1.0.0", "1.0.0"} );
+        //args.add( new Object[] {"1.2.0", "5.2.0", "1.1.0", "1.0.0"} );
        args.add( new Object[] {"1.3.2", "5.3.2", "1.1.1", "1.0.0"} );
-        args.add( new Object[] {"1.4.2", "5.4.2", "1.1.1", "1.0.0"} );
-        args.add( new Object[] {"1.5.2", "5.5.2", "1.2.0", "1.1.0"} );
+        //args.add( new Object[] {"1.4.2", "5.4.2", "1.1.1", "1.0.0"} );
+        //args.add( new Object[] {"1.5.2", "5.5.2", "1.2.0", "1.1.0"} );
        args.add( new Object[] {"1.6.2", "5.6.2", "1.2.0", "1.1.0"} );
-        //args.add( new Object[] { "1.6.0-SNAPSHOT", "5.6.0-SNAPSHOT", "1.2.0", "1.1.0" } );
+        //args.add( new Object[] {"1.7.2", "5.7.2", "1.2.0", "1.1.0"} );
+        args.add( new Object[] {"1.8.2", "5.8.2", "1.2.0", "1.1.2"} );


Dead code should be removed ... or commented why and when we want to restore it.

My motivation was to remove some config because the build takes long with every next config, and these configs have been tested already long enough in our tests, and the new ones have not been tested yet.

slawekjaranowski · 2022-03-05T20:40:23Z

maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm

+** JUnit5 Suite
+
+  For more information see this
+  {{{https://github.com/apache/maven-surefire/tree/master/surefire-its/src/test/resources/junit5-suite}example}}.
+
+---+
+<dependencies>
+    <dependency>
+        <groupId>org.junit.jupiter</groupId>
+        <artifactId>junit-jupiter-api</artifactId>
+        <version>5.8.0</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.junit.platform</groupId>
+        <artifactId>junit-platform-suite-api</artifactId>
+        <version>1.8.0</version>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.apache.maven.plugins</groupId>
+            <artifactId>maven-surefire-plugin</artifactId>
+            <configuration>
+                <includes>
+                    <include>JUnit5Tests</include>
+                </includes>
+            </configuration>
+            <dependencies>
+                <dependency>
+                    <groupId>org.junit.jupiter</groupId>
+                    <artifactId>junit-jupiter-engine</artifactId>
+                    <version>5.8.2</version>
+                </dependency>
+                <dependency>
+                    <groupId>org.junit.platform</groupId>
+                    <artifactId>junit-platform-suite-engine</artifactId>
+                    <version>1.8.2</version>
+                </dependency>
+            </dependencies>
+        </plugin>
+    </plugins>
+</build>


Looks like next complicated ... why dependency in project and plugin
Even if we we support it in code for some reason we shouldn't give such examples ... project dependency should be enough.

Maybe we should also link to JUnit documentation.
https://junit.org/junit5/docs/current/user-guide/#junit-platform-suite-engine

Because there are more alternatives. So the JUnit5 team separated API from impl and they always stated that the user does not need to access the impl of the engine.
If you like I put engines to the dependencies. Both would work. It's just matter of taste.

IMHO the users don;t care if they have an access to the engine internals. So I wil use only project deps. thx

agree with @slawekjaranowski such extra configuration complexity will be confusing for users. and if given as an example in the users documentation the users will simply copy/paste this over complicated configuration whereas they might not need it.

Tibor17 · 2022-03-05T21:21:52Z

@slawekjaranowski
done

…t-platform-suite-engine

slawekjaranowski · 2022-03-06T08:42:36Z

maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm

+<dependencies>
+    <dependency>
+        <groupId>org.junit.jupiter</groupId>
+        <artifactId>junit-jupiter-engine</artifactId>
+        <version>5.8.2</version>
+        <scope>test</scope>
+    </dependency>
+    <dependency>
+        <groupId>org.junit.platform</groupId>
+        <artifactId>junit-platform-suite-engine</artifactId>
+        <version>1.8.2</version>
+        <scope>test</scope>
+    </dependency>
+</dependencies>


I'm still not sure if we want to write documentations for external products .... 😄
But from other side we should be consistent with original product
documentation.
https://junit.org/junit5/docs/current/user-guide/#junit-platform-suite-engine-setup-required-dependencies

There is:

Required Dependencies

junit-platform-suite-api in test scope: artifact containing annotations needed to configure a test suite

junit-platform-suite-engine in test runtime scope: implementation of the TestEngine API for declarative test suites

@slawekjaranowski
Slawomir, we have never repeated "their" documentation. We have always declared Surefire configuration in order to run some tests, support some framework, declaring features we support and we made a fix to support these features.
The JUnit documentation should mentioned us as Surefire, we have to do it, we are the one who should understand how the framework works and how it should be used and configured in the Surefire/Failsafe, not opposite.

slawekjaranowski · 2022-03-06T08:44:01Z

maven-surefire-plugin/src/site/apt/examples/junit-platform.apt.vm

+            <artifactId>maven-surefire-plugin</artifactId>
+            <configuration>
+                <includes>
+                    <include>JUnit5Tests</include>


I afraid that users can simply comply such configurations .... and will be surprised

Don't be surprised! What is the point of Junit5 Suite? It's the same point that the Junit4 suite has!
The Point is to start the suite class which is a similar case is in your Surefire project. The suite children are executed by selecting JUnit5Tests and not by surefire provider and that the reason you have to select it. You must select the suite and not the children. Why we do not use the parameter test? Because there is a significant difference between includes and test. The test is a filter performing the selection inside of the JUnit which cannot be used here because this way you are not able to select the root class JUnit5Tests and you filter out all children. The includes does exactly what we want, it does not perform filtering inside of JUnit, it performs selection of classes that you send to the JUnit framework to execute it.

such explanation should be put in example,
what inclusion is for and what value should contains.

slawekjaranowski · 2022-03-07T15:20:55Z

surefire-its/src/test/resources/junit5-suite/pom.xml

+            <dependency>
+              <groupId>org.junit.jupiter</groupId>
+              <artifactId>junit-jupiter-engine</artifactId>
+              <version>5.8.2</version>


does should be the same version as for api?
the same for suite-api and suite-engine

Support junit-platform-runner and junit-platform-suite-engine in plug…

7bc9147

…in dependencies

Tibor17 requested a review from slawekjaranowski March 5, 2022 20:04

slawekjaranowski requested changes Mar 5, 2022

View reviewed changes

according to Slawomir's hints

fe95deb

added the link https://junit.org/junit5/docs/current/user-guide/#juni…

3a1de7a

…t-platform-suite-engine

slawekjaranowski reviewed Mar 6, 2022

View reviewed changes

slawekjaranowski reviewed Mar 7, 2022

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Tibor17 commented Mar 5, 2022 •

edited

Loading

slawekjaranowski Mar 5, 2022

Tibor17 Mar 5, 2022 •

edited

Loading

slawekjaranowski Mar 5, 2022

Tibor17 Mar 5, 2022 •

edited

Loading

Tibor17 Mar 5, 2022

olamy Mar 5, 2022 •

edited

Loading

Tibor17 commented Mar 5, 2022

slawekjaranowski Mar 6, 2022

Tibor17 Mar 6, 2022

slawekjaranowski Mar 6, 2022

Tibor17 Mar 6, 2022

slawekjaranowski Mar 7, 2022

slawekjaranowski Mar 7, 2022

Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Are you sure you want to change the base?

Support junit-platform-runner and junit-platform-suite-engine in plugin dependencies #484

Conversation

Tibor17 commented Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Tibor17 Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tibor17 Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olamy Mar 5, 2022 • edited Loading

Choose a reason for hiding this comment

Tibor17 commented Mar 5, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tibor17 commented Mar 5, 2022 •

edited

Loading

Tibor17 Mar 5, 2022 •

edited

Loading

Tibor17 Mar 5, 2022 •

edited

Loading

olamy Mar 5, 2022 •

edited

Loading