On 19 November 2010 18:58, Kristian Rosenvold <[email protected]> wrote: > I have been refactoring quite heavily on the surefire plugin the last > weeks. This has been entirely non-functional with the intent of > loosening the internal dependencies (without breaking the existing > plugin) enough to create a starting point for solving SUREFIRE-141. >
Cool > At the moment I am quite satisfied with > where the plugin is at, and we need to take some decisions on how > the SUREFIRE-141 can be solved. Those of you who are familiar with the > "old" surefire might want to have a look at svn HEAD, since there's been > considerable changes around the booter. At the moment I feel this > discussion is required before I can move on: > I'll have to see if I can find some cycles... work is mad while they try to find my replacement! > I have two different proposals here. Both of them have some details that > need to be solved, but I have come to the conclusion that the key issue > to be resolved is how parameters arrive at the individual providers: > > A) "Pile it up" > > Adding all the provider-specific settings to the main surefire plugin > was probably a mistake; but this solution assumes we'll have to live > with that. The current list of parameters at > http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html is > probably reasonably close to complete for java xUnit, leaving room for > some future expansion there might be 5-10 more for java, and maybe (wild > guess) 20-30 other parameters for other languages, assuming they re-use > the existing parameters for similar meanings. All in all it could be > handled by documentation. > - Technically we could just transparently serialize ANY parameter given > to the surefire-plugin through the booter to the provider, without the > surefire plugin trying to find out if the provider will use them or not. > The provider knows its own requirements and will sort it out. > - Any new parameters required by a new provider would have to be added > to the surefire-plugin. Or we could use tricks (I say tricks, but they're not really so much tricks as more advanced ways of doing things) like, e.g. enforcer uses to basically let the provider's config be exposed through a specific sub-option basically that sub-option would have a custom xml deserializer that we could map to the providers configuration, eliminating the need to pass extra through, and in fact allowing us to fail faster if the configuration is invalid... though I am not sure how far along the lifecycle our deserializer gets invoked, and tooling such as intellij and perhaps eclipse would not be able to give autocomplete when editing the custom section. > - Detect user-specified providers in the suerfire-plugin's > dependencies, which would disable the current autodetection. I think if we use the SPI mechanism to detect providers... but now that I think about is perhaps you might want to have two providers running different tests from the same execution... > - The only real piece of work remaining for this is cleaning up the > provider instantiation & parameter transfer. Could/would probably be > feature complete with 2.7 release. > > B) Per-provider plugins > Surefire is basically a library providing classpath scanning, forking > and reporting services. Extract the necessary interfaces so that a > plugin can simply declare a dependency on the required services and have > them wired in via plexus or similar. > - Extract interfaces so that similar features (e.g. fork configuration, > classloader settings and reporting settings) become homogenous in terms > of plugin parameters, even though there is one distinct mojo per > provider. Assume no more re-use between plugins than this. > - Deprecate the current surefire plugin and declare that no new > parameters EVER will be added to it. All new parameters will only be > added to the provider-specific plugins. > - Make the deprecated surefire plugin delegate to the 4 well known new > mojos (testng, junit3, junit4, junit47), so that the deprecated > plugin can be kept indefinitely compatible at surefire 2.6 level. Users > wishing post-2.6 features will have to declare an explicit plugin > dependency to the specific mojo. Not sure how this would fit in with the pre-3.0 builds... we might be screwing the over if we are doing the delegation > - Make all surefire mojos implement a specific interface/marker of some > sort. The old surefire-plugin will have to detect the presence of any > such mojo; if any such explicit declaration exists, the old surefire > does nothing. > - Converting from old-style "surefire" declaration to the new > per-provider-mojo should basically be about replacing GAV identifier in > the pom to the provider-specific version, since this "by definition" > should accept all the same parameters as the existing surefire mojo. > - The important stuff (extracting the libraries that can be used by > "anyone") should be doable for 2.7, maybe converting one or two of the > current providers in the process; I like using the junit47 provider for > this stuff since it's mostly used by folks running // junit. Porting ALL > the existing providers to this schema can probably wait until 2.8-2.9 > ish. An advantage of this approach would be the ability to NOT finalize > the api's for 2.7 but to be able to adjust this slightly if/when someone > wants to write an independent provider (or fork one of the existing ones > - the guy who wanted to do parallel junit 3 comes to mind), and maybe > aim for a "surefire 3.0" like target for the first officially frozen > api. > > My only uncertainty wrt this second option is how failsafe would fit in; > maybe Stephen has some thoughts on this... > I'm leaning towards option A but really I need to get some cycles and look at where the code is and see what I think we should do... maybe we should fork a branch and explore option A (with my tweaks) on the branch, see where that takes us and then throw the branch away and to the "right thing" whatever we think that might be ;-) > > What do you think ? > > Kristian > > > > > --------------------------------------------------------------------- > 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]
