You're going to need another external plugin to merge the plugin descriptors if
you do this, since by default it doesn't take plugin parameters from external
dependencies. Otherwise the plan sounds fine and minimises disruption.
Refactoring to remove duplication is fine, but I'd be cautious about doing too
much work on integration test specifics in here without taking the time to fix
it properly in the core - certainly something to look into after 3.0.
As for the 2.5 ITs - I'm not quite sure what's going on there. My recollection
was that they were modelled after the Maven ones, so maybe they are actually
meant to run separately? Dan F should be able to elaborate. As for coverage, I
don't know for certain, but I had the impression it was pretty good after his
last round of work.
- Brett
On 05/01/2010, at 7:17 AM, Stephen Connolly wrote:
> 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
>
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
