The scanning logic has been moved from the forked side to the plugin
side, which is why using "getDirectoryScanner" on the fork side is
discouraged.
The plugin communicates to the fork what work is to be done.
The overall design should hold for your use case too, although there
may very well have
The issue, as I see it, is that ProviderParameters now tells you to use
getScanResult() and warns against using getDirectoryScanner() and as
ScanResult is heavily biased towards the .class assumption there is no
advertised future-proof way to scan for tests that are not .class files.
This seems a
The interface org.apache.maven.surefire.providerapi.SurefireProvider
generally leaves it ut to the provider to determine what kind of
object describes a test. Up until fairly recently, most of the
providers used arbitrary strings, which *could* map 1:1 to a class, or
could be something totally diff
Kristian,
I was looking to use Surefire to help running tests in scripting
languages...
i.e. where the .class file is not necessarily created at all.
I notice that Surefire's Providers API leans heavily on ScanResult which
seems to be biased towards assuming that there is a .class file for each
