crizzis commented on a change in pull request #487: URL: https://github.com/apache/maven-surefire/pull/487#discussion_r824921536
########## File path: surefire-providers/surefire-junit-platform/pom.xml ########## @@ -136,6 +136,47 @@ </includes> </configuration> </plugin> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-jar-plugin</artifactId> + <executions> + <execution> + <id>api-jar</id> + <phase>package</phase> + <goals> + <goal>jar</goal> + </goals> + <configuration> + <classifier>api</classifier> Review comment: > Can you explain how the customer would implement the interface TestSelectorFactory you have introduced? What types of sources can be filtered and how they can be configured? Absolutely. Here is my implementation for ArchUnit's [`FieldSelector`](https://github.com/TNG/ArchUnit/blob/2f3ff7dccbe3e3d8900604801fd545dd0c2e70d8/archunit-junit/junit5/engine-api/src/main/java/com/tngtech/archunit/junit/FieldSelector.java): ``` package com.tngtech.archunit.junit.surefire; import com.tngtech.archunit.junit.FieldSource; import org.apache.maven.surefire.junitplatform.TestSelectorFactory; import org.junit.platform.engine.TestSource; public class FieldSelectorFactory implements TestSelectorFactory { @Override public boolean supports(TestSource testSource) { return testSource instanceof FieldSource; } @Override public String getContainerName(TestSource testSource) { return ((FieldSource) testSource).getClassName(); } @Override public String getSelectorName(TestSource testSource) { return ((FieldSource) testSource).getFieldName(); } } ``` It solves the problem of adding support for applying the same filtering logic Surefire now applies to methods, to other test sources (`FieldSource` in this case). In case you're unfamiliar with ArchUnit, here's what an ArchUnit test might look like: ``` @AnalyzeClasses(packages = "com.tngtech.archunit.example.layers") public class CodingRulesTest { @ArchTest private final ArchRule loggers_should_be_private_static_final = fields().that().haveRawType(Logger.class) .should().bePrivate() .andShould().beStatic() .andShould().beFinal() .because("we agreed on this convention"); } ``` As you can see, test cases are represented by *fields*, and not *methods*. This is also why the default Surefire `include / exclude` filters do not work. > JUnit5 SPI do not exist with same purpose? Yes, of course it exists, and that's exactly what ArchUnit does under the hood. There's no way to influence Surefire filtering logic from inside a JUnit extension, though. I've already verified providing this implementation of the new SPI in ArchUnit solves [the linked ArchUnit issue](https://github.com/TNG/ArchUnit/issues/641) for Surefire. I'm now about to suggest similar extensibility to other build tools. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org