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


Reply via email to