[
https://issues.apache.org/jira/browse/SUREFIRE-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980575#comment-16980575
]
M.P. Korstanje commented on SUREFIRE-1724:
------------------------------------------
> Do you think that {{LauncherDiscoveryRequestBuilder}} can operate over a list
> of JAR file, means their Path-s of location?
Yes. That is possible. Using the class path root selector you can provide a
list of class path roots. These can be either jar files or directories.
{code:java}
DiscoverySelectors.selectClasspathRoots(Set.of(
Paths.get("file:/path/to1.jar"),
Paths.get("file:/path/to2.jar"),
Paths.get("file:/path/to3.jar")
));
{code}
> I guess this implementation of {{LauncherDiscoveryRequestBuilder}} takes a
> look in the classpath or the classloader.
When the discover request is executed by the JUnit Platform Launcher a
TestEngine implementation may potentially scan for classes. JUnit Jupiters
implementation of the TestEngine for example will scan for classes with @Test
annotated methods. Cucumbers implementation on the other hand doesn't - it only
looks for feature files.
> I want to use the discovery via {{LauncherDiscoveryRequestBuilder}}
excluding the system classloader. I don't want this because i don't want the
classes been loaded while performing the discovery phase.
That is clear and makes allot of sense.
> Doing it in IsolatedClassLoader is feasible for the forkCount > 1 but you may
> have noticed that we are reworking several implementations (TCP/IP
> interprocess communication, Reports API to support future JUnit5 reports,
> Provider interface) and these selectors would also require splitting Provider
> interface in two at least.
> ....
> This effectivelly removes the IsolatedClassLoader in Maven process and
> enables the subprocess to perform filtering of test file within the same JVM
> where it would be executed and we solved the old issue requested by the
> Arquillian. I guess that DiscoverySelectors may fit here as well.
That sounds about right. Though I'm not into all the details.
Aside from splitting the Provider interface into to a discovery and execution
part, it can also no longer use classes to identify tests. The JUnit platform
identifies tests by a UniqueId. Which can be serialized to string and parsed
again. So to distribute tests across forks the fork starter and booter would
have to work with strings (maybe wrap them in something nice) rather then
classes.
> Support JUnit Platform DiscoverySelectors
> ------------------------------------------
>
> Key: SUREFIRE-1724
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1724
> Project: Maven Surefire
> Issue Type: Improvement
> Reporter: M.P. Korstanje
> Priority: Major
>
> The JUnit Platform defines multiple
> [DiscoverySelectors|https://junit.org/junit5/docs/5.0.2/api/org/junit/platform/engine/DiscoverySelector.html]
> to discover tests in different locations. This allows TestEngines to
> discover tests in classes, the class path root, resource root, files, ect.
> Currently Surefire supports TestEngine implementations through the
> JUnitPlatformProvider. However the JUnitPlatformProvider only issues
> discovery requests for classes that have already been discovered by Surefire.
> Additionally if no tests were discovered by Surefire then no test discovery
> requests will be issued at all.
> This means that Surefire does not fully utilize the discovery capabilities of
> the JUnit Platform and makes it impossible to use the JUnitPlatformProvider
> for test frameworks that do not have class based tests such as Cucumber.
> To make Cucumber work at the very least the class path root discovery
> selector would have to be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
