What if we provided some of a core utilities like the classpath scanning, forking, and reporting services and made individual plugins like a junit-maven-plugin, and testng-maven-plugin?
I know that Cedric would work on a testng-maven-plugin but isn't overly keen on working on Surefire. If we went that route of simple, separate plugins we could either add both plugins to the lifecycle to provide the expected behavior. I think only B) is a viable option if we don't separate the plugins because the authors of the tools don't really want to get involved which is a sign, to me at least, that something is wrong. On Nov 19, 2010, at 1:58 PM, Kristian Rosenvold 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. > > 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 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. > - Detect user-specified providers in the suerfire-plugin's > dependencies, which would disable the current autodetection. > - 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. > - 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... > > > What do you think ? > > Kristian > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
