Github user ok2c closed the pull request at:
https://github.com/apache/maven-wagon/pull/4
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Github user andrewgaul closed the pull request at:
https://github.com/apache/maven-surefire/pull/27
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Github user mfriedenhagen closed the pull request at:
https://github.com/apache/maven-surefire/pull/28
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
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
