You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2010/11/19 19:58:14 UTC
Solving SUREFIRE-141 ; pluggable providers
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Rex Hoffman <re...@e-hoffman.org>.
I don't think that the option C would prevent a fairly painless migration
path. Though it's been a while since I've used the older junits, so I don't
know.
The libraries to configure the tests outside of maven would be need for the
standard testing environments (junit, testng), and would hopefully work in
IDEs as well.
I think we can eliminate the problem your trying to solve by moving the
means of configuring the test library outside of maven. Maven just tried to
do to much here. This was helpful to gain initial adoption, but ultimately
just leads to unneeded coupling, for both maven and logical runtime of the
tests maven runs.
Maybe allow config from both the plugin and lib initially, and on a 3.0 drop
support for the non-generic plugin config?
We could still pass info as system parameters, through to the helper
library, which users could have default overrides for set in there IDEs....
The work your doing to decouple various parts of the test plugin and it's
apis is very cool. Thanks for tackling this problem! Apologies for being a
little opinionated on the matter.
Rex
On Fri, Nov 19, 2010 at 12:50 PM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:
> I think what you're advocating is much of what one would achieve with
> per-provider plugins. The idea here is to extract the common
> functionality of surefire (some of which is *hard* to get right) into
> separate module(s) which each plugin can choose to use or not. To
> achieve a certain kind of end-user consistency in how the user specifies
> parameters they can choose to use the "common properties" interfaces to
> define the mojo attributes.
>
> The net long term effect is that you'd probably end up with a number
> of different testng providers, one less-is-more plugin or a "surefire
> traditional testng" plugin and another "more is more" plugin that would
> support the whole shebang and then some. And the ones that support
> forking execution would *probably* be using the surefire forking module,
> but the per-provider plugin strategy mandates very few such absolute
> choices, since the different mojos can choose which bits to use free
> of constraints from what the others are doing.
>
> Personally I will not implement any solution that does not have a decent
> migration path for existing users, so any option that alienates existing
> users is a clear -1 from me.
>
> Part of the problem with existing surefire is that it's overly
> prescriptive in terms of what must be shared/common between the
> different providers. And quite a few of these assumptions are
> just not generalizable; they turned out to be relevant for only 1
> provider.
>
> So I can easily see this turning into a small handful of old-skool
> providers here at apache, with various forks popping up for less-is-more
> or more-is-more at github. I kind of like that kind of ecosystem, which
> would give a freedom of choice that is not available currently.
>
> Kristian
>
>
>
> fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman:
> > I have a slight concern.
> >
> > It goes into testing portability (running in maven, or eclipse, idea,
> > netbeans, or via command line)
> > In short, the smarter we make maven about running tests, the less easy it
> is
> > for a developer to run that same test via IDE or something similar.
> >
> > I'll give two common examples.... and hope it makes the point.
> >
> > If we add test-ng listeners to the maven surefire plugin config, those
> same
> > tests wont run the same in eclipse without adding the listeners as
> > annotations to the class. Eliminating the need to add the Listeners to
> > maven config in the first place.
> >
> > Same is true of the life cycle phases around integration tests.
> >
> > People often start jetty and run selenium style test in the integration
> test
> > phase via maven. It might be better to use an annotations or something
> > similar on that tests that loads the needed data and starts the
> application
> > (if not already running). That way a right click and a "run as" in an
> IDE
> > would be enough to run the test.
> >
> > Seems like energy is being put into allowing and promoting sub-optimal
> > solutions. Maybe helper libraries meant to be used by test developers,
> that
> > are not tied to maven, but make the running of tests in maven cleaner
> would
> > be a better approach to promote? Move the mountain as it were....
> >
> > So in short maybe a C approach.
> >
> > Keep maven test running as simple and unconfigurable as possible, provide
> > some libraries and documentation to bridge any gaps. Forking config,
> > sure... Ant style file includes, definitely, anything that has to do
> > specifically with the configuration of any implementation of a test
> runner
> > should not possible via maven.
> >
> > Not sure if this is useful with what has been already implemented. But
> > while getting companies to switch to maven and start testing, it has
> proven
> > a challenge in the past, and this solution has been the one I found that
> > worked for devs, qa and automation teams.
> >
> > I wrote a small library for testNG:
> >
> >
> http://www.epolity.net/blog/2010/04/testng-extensions-to-bridge-the-small-gap-between-maven-and-testng/
> >
> >
> > and found that the less config I put in maven, the easier it was to
> develop
> > and run tests.
> >
> > My two pennies....
> >
> > Rex
> >
> > On Fri, Nov 19, 2010 at 10:58 AM, Kristian Rosenvold <
> > kristian.rosenvold@gmail.com> 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.htmlis
> > > 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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Kristian Rosenvold <kr...@gmail.com>.
I think what you're advocating is much of what one would achieve with
per-provider plugins. The idea here is to extract the common
functionality of surefire (some of which is *hard* to get right) into
separate module(s) which each plugin can choose to use or not. To
achieve a certain kind of end-user consistency in how the user specifies
parameters they can choose to use the "common properties" interfaces to
define the mojo attributes.
The net long term effect is that you'd probably end up with a number
of different testng providers, one less-is-more plugin or a "surefire
traditional testng" plugin and another "more is more" plugin that would
support the whole shebang and then some. And the ones that support
forking execution would *probably* be using the surefire forking module,
but the per-provider plugin strategy mandates very few such absolute
choices, since the different mojos can choose which bits to use free
of constraints from what the others are doing.
Personally I will not implement any solution that does not have a decent
migration path for existing users, so any option that alienates existing
users is a clear -1 from me.
Part of the problem with existing surefire is that it's overly
prescriptive in terms of what must be shared/common between the
different providers. And quite a few of these assumptions are
just not generalizable; they turned out to be relevant for only 1
provider.
So I can easily see this turning into a small handful of old-skool
providers here at apache, with various forks popping up for less-is-more
or more-is-more at github. I kind of like that kind of ecosystem, which
would give a freedom of choice that is not available currently.
Kristian
fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman:
> I have a slight concern.
>
> It goes into testing portability (running in maven, or eclipse, idea,
> netbeans, or via command line)
> In short, the smarter we make maven about running tests, the less easy it is
> for a developer to run that same test via IDE or something similar.
>
> I'll give two common examples.... and hope it makes the point.
>
> If we add test-ng listeners to the maven surefire plugin config, those same
> tests wont run the same in eclipse without adding the listeners as
> annotations to the class. Eliminating the need to add the Listeners to
> maven config in the first place.
>
> Same is true of the life cycle phases around integration tests.
>
> People often start jetty and run selenium style test in the integration test
> phase via maven. It might be better to use an annotations or something
> similar on that tests that loads the needed data and starts the application
> (if not already running). That way a right click and a "run as" in an IDE
> would be enough to run the test.
>
> Seems like energy is being put into allowing and promoting sub-optimal
> solutions. Maybe helper libraries meant to be used by test developers, that
> are not tied to maven, but make the running of tests in maven cleaner would
> be a better approach to promote? Move the mountain as it were....
>
> So in short maybe a C approach.
>
> Keep maven test running as simple and unconfigurable as possible, provide
> some libraries and documentation to bridge any gaps. Forking config,
> sure... Ant style file includes, definitely, anything that has to do
> specifically with the configuration of any implementation of a test runner
> should not possible via maven.
>
> Not sure if this is useful with what has been already implemented. But
> while getting companies to switch to maven and start testing, it has proven
> a challenge in the past, and this solution has been the one I found that
> worked for devs, qa and automation teams.
>
> I wrote a small library for testNG:
>
> http://www.epolity.net/blog/2010/04/testng-extensions-to-bridge-the-small-gap-between-maven-and-testng/
>
>
> and found that the less config I put in maven, the easier it was to develop
> and run tests.
>
> My two pennies....
>
> Rex
>
> On Fri, Nov 19, 2010 at 10:58 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> 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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Kristian Rosenvold <kr...@gmail.com>.
fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman:
Rex,
I don't really see there is any disagreement between what you suggest
and the per-provider strategy. I also agree with your long term goal,
but I want decent migration strategies.
The gap between the features implemented in surefire and the features in
the test frameworks is closing, but unfortunately there is a lot of
tension still. At least with junit 4.8.2 there are a *lot* of issues
that need to be solved somewhere else, and there is quite a lot of stuff
that real projects do that surefire solves nicely.
So we keep a nice migration path by extracting the current stuff into
separate modules that other providers can choose to use or not. Surefire
tries to cater for widely different versions of testing tools. So you
could say that the features in surefire represent the *sum* of all the
missing features in all testing tools, and due to high cohesion in the
(,2.6] implementation it creates bloat. Which is why componentizing
surefire makes sense; it's also an argument for deprecating the
front-controller surefire-plugin.
An upgrade path that starts with "upgrade to junit 4.9 and jdk6" is not
an option. I will happily make the "Zero config" junit/testng plugin
once this base infrastructure is in place, it should be less than 20
lines of clean code once the componentization is done.
But it won't work on *my* projects, at least not with current versions
of junit ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Rex Hoffman <re...@e-hoffman.org>.
I have a slight concern.
It goes into testing portability (running in maven, or eclipse, idea,
netbeans, or via command line)
In short, the smarter we make maven about running tests, the less easy it is
for a developer to run that same test via IDE or something similar.
I'll give two common examples.... and hope it makes the point.
If we add test-ng listeners to the maven surefire plugin config, those same
tests wont run the same in eclipse without adding the listeners as
annotations to the class. Eliminating the need to add the Listeners to
maven config in the first place.
Same is true of the life cycle phases around integration tests.
People often start jetty and run selenium style test in the integration test
phase via maven. It might be better to use an annotations or something
similar on that tests that loads the needed data and starts the application
(if not already running). That way a right click and a "run as" in an IDE
would be enough to run the test.
Seems like energy is being put into allowing and promoting sub-optimal
solutions. Maybe helper libraries meant to be used by test developers, that
are not tied to maven, but make the running of tests in maven cleaner would
be a better approach to promote? Move the mountain as it were....
So in short maybe a C approach.
Keep maven test running as simple and unconfigurable as possible, provide
some libraries and documentation to bridge any gaps. Forking config,
sure... Ant style file includes, definitely, anything that has to do
specifically with the configuration of any implementation of a test runner
should not possible via maven.
Not sure if this is useful with what has been already implemented. But
while getting companies to switch to maven and start testing, it has proven
a challenge in the past, and this solution has been the one I found that
worked for devs, qa and automation teams.
I wrote a small library for testNG:
http://www.epolity.net/blog/2010/04/testng-extensions-to-bridge-the-small-gap-between-maven-and-testng/
and found that the less config I put in maven, the easier it was to develop
and run tests.
My two pennies....
Rex
On Fri, Nov 19, 2010 at 10:58 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Jason van Zyl <ja...@maven.org>.
I'm also thinking of parity with Eclipse where separate runners have been created, and anything that helps the CLI execute as it does it the IDE helps. I know that at least for TestNG if Cedric worked on both the Eclipse plugin (which he does) and the Maven plugin we'd probably be closer to parity.
On Nov 20, 2010, at 6:35 AM, Kristian Rosenvold wrote:
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kurosawa
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Kristian Rosenvold <kr...@gmail.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Stephen Connolly <st...@gmail.com>.
On 19 November 2010 18:58, Kristian Rosenvold
<kr...@gmail.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Kristian Rosenvold <kr...@gmail.com>.
ma., 22.11.2010 kl. 16.05 -0500, skrev Jason van Zyl:
> 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?
This is what I am working on ATM. Getting the utilities extracted and
loosely coupled. If we build some simple
provider detection mechanism into surefire we could probably just leave
the question of the plugin parameters for later, assuming that most
modern testing architectures will require less configuration
and not more.
I feel I'm not entirely comfy with how to express the "dispatcher" role
that the current surefire plugin has, where it passes on control to
specific providers - currently this is expressed in the mother of all
big ugly if-blocks within the existing plugin. And it seems to me like
this must be handled in some way ? (Or we could just request people to
disable surefire in their pom when they upgrade to testng-maven-plugin,
or maybe the testng-maven-plugin could just disable surefire by its mere
presence)
> I know that Cedric would work on a testng-maven-plugin but isn't overly keen on working on Surefire.
I hope he'll take another look in a week or two when I finish 2.7; which
is my current goal - give or take a week.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
Posted by Jason van Zyl <ja...@maven.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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)