fr., 19.11.2010 kl. 23.18 +0000, skrev Stephen Connolly > > 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.
I think tool support is of the essence: I know intellij uses reflection to get autocomplete on the plugins, and this is one of the features that keep me sane in the xml jungle ;) If we split in per-provider plugins we could even use java5 enum-types (and get autocomplete on values ?? Would that be backward compatible ?) for the providers that are java5 spciefic. > 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... Yes, you might even want to support mixed providers in one module. We could use dependencies to the surefire plugin with an SPI mechanism, but I have problems on how this would work with multiple executions, and it seems to be taking us nowhere nice. Hence I gradually shifted my preference to a per-provider mojo option. > > - 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 I'm not sure I follow you here? > 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 ;-) > Currently I've just broken down most of the extreme cohesion that used to be there. I have not done the "last" finish which constitutes designing proper public API's but I'm sure you'll see that's not much more work. I think I can extract the "components" properly (as separate modules with well defined well documented interfaces) without actually changing the external api or providing any "official" api (because it isn't official until we say so ;) This would probably only increase the quality further. But we really need to solve the issue of those parameters. I started out thinking that we'd just pile it all onto the surefire-plugin, but I must admit as I've gotten deeper and deeper into this issue I think per-provider plugins are the way to go ;) Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
