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 been some changes that make this work less well. It's probably not a very large change to get back to what you need. Kristian 2013/10/21 Stephen Connolly <[email protected]>: > 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 retrograde step IMHO... > > On the other hand, I can appreciate that some of this may have been part of > the "let people run tests from .jar files also" effort (which is a big +1 > from my PoV) though I do not see why this needs to leak the assumption that > tests are contained in .class files. > > > On 21 October 2013 07:26, Kristian Rosenvold > <[email protected]>wrote: > >> 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 different, like a url. The implementation >> was changed by "someone" from string->class, for some reason I do not >> entirely remember; but the interface still leaves it up to the >> provider. Unless there has been some leaking in the abstractions, it >> should hold. >> >> But it should (at least in theory) still be totally up to the >> provider; it returns a bunch of items in the "getSuites" method, and >> will receive each item in the iterator in the "invoke" item. >> >> Kristian >> >> 2013/10/21 Stephen Connolly <[email protected]>: >> > 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 >> > and every test. >> > >> > Is this something that you think could be easily unwound, or am I better >> > creating a separate test engine for non-class based tests >> > >> > -Stephen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
