I see the common code being aabstract base class that extends
abstractmojo
that way, we have less regression risks
anything else will be more of a regression risk IMHO
but I'll take a look while refactoring. my main concern is that the
surefire test coverage is not as good as I'd like (andi guess i'm not
the only one, given the slow release rate)
Sent from my [rhymes with tryPod] ;-)
On 4 Jan 2010, at 20:00, Kristian Rosenvold <kristian.rosenv...@gmail.com
> wrote:
On Mon, 2010-01-04 at 17:43 +0000, Stephen Connolly wrote:
2. Refactor maven-surefire-plugin taking the code that is common with
failsafe into common module
3. Refactor maven-failsafe-plugin to use the common module.
In pseudo code SurefirePlugin would be reduced to
execute() {
common.runTests();
}
Failsafe's integration-test mojo would become
execute() {
try {
common.runTests();
} catch (Throwable t) {
// ignore
}
}
At a birds-eye view the surefire-plugin does the following things:
- Based on detected version of test framework, chooses provider (ie,
testng, junitxxx).
- Set up parameters for the different providers
- Sets up the surefire-booter (threading models etc, selected
surefire-provider and parameters are passed through the booter)
- Invokes the booter
The main problem I see with this design is that it forces the outer
level surefire-plugin to contain a lot of knowledge about which
configuration the specific providers require. So while the individual
plugins are fairly nice & clean, the outer surefire-plugin seems
to know way too much about what should have been inner workings of the
different plugins. Additionally there are at least two generations of
how this parameter transfer is being done between surefire-provider
and
the providers.
Is there any way to reduce (or at least avoid increasing) this problem
when extracting the common functionality ? I somehow see an additional
layer of complexity being added here, and I frankly think its more
than
complex enough already. How will you transfer the parameters to the
common code ?
This may be stretching it a bit, but I have been thinking that the
surefire-plugin design should have been inverted slightly, that the
configuration really should be (plexus-)wired or otherwise transfered
directly into an object that the selected surefire-provider gives to
the
surefire-plugin. In that way the surefire-plugin could be relieved of
detailed knowledge of what's going on inside the different
providers, or
at least the parameter object construction could be shared among the
providers in a different manner. But I suppose that's a longer shot,
but
there's an awful lot of if/then/elses in the surefire-plugin.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
