How do we make sure different plugins use parameter names consistently?
I would like to align Tycho OSGi test plugin with Surefire, for example,
but I don't see a way to do this, to be honest.
--
Regards,
Igor
On 10-11-22 04:05 PM, Jason van Zyl wrote:
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
