> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: dimanche 17 avril 2005 04:34
> To: Maven Developers List
> Subject: Re: [M2] Clover plugin ideas and questions
> 
> I remember I was going to reply to this :)
> 
> Vincent Massol wrote:
> 
> >Hi,
> >
> >2/ Option 2: Generate instrumented sources in target/ somewhere and
> somehow
> >convince the compile plugin to use those sources rather than the ones in
> >src/main/java.
> >
> >
> I'd definitely say 2. I don't like the clover:on command - it should be
> implicit in the clover:report goal.

Reporting is only a second step. The first step is that you need to
instrument sources, get them to be compiled and executed. You don't want to
execute the report right away. I think it should really be a second step not
linked to the first step of getting the clover database ready (because the
clover db can be enriched in different manners, including running manual
tests). This is really how Clover works and this is why you have different
Ant tasks of CLI tools in Clover (cloverInstr and *Reporters).

Option 2 fits nicely for doing this but this is going in the direction of
clover:on as it's exactly what it was doing.
 
> >But this option seems less good because how do I get the WAR plugin to
> >incorporate instrumented sources (for example) so that functional tests
> can
> >be run?
> >
> >Any advice for doing this in m2?
> >
> >
> >
> Well, if your WAR is going to be used in this way, there is probably a
> need to modify how the WAR is named as well as inserting the classes in
> there, so you don't end up with instrumented WARs getting deployed to
> repositories or worse.

True but that's the user's choice. He may want to have the instrumented code
deployed (I do for example because I want acceptance tests to run with
Clover so that I can check how much they cover of the code). Of course,
there will also be some runs without clover but that's me the user who
decides this.

> I'm still working on the idea of alternate lifecycles (there is a JIRA
> ticket regarding idea:idea and generated sources that covers the same
> idea, and this applies to all reporting). What this means is that
> clover:report would fork a lifecycle instance to run everything under
> its own parameters. 

More precisely, what parameters are you talking about?

> You could choose the appropriate lifecycle goal to
> execute (just test by default, but maybe integration-tests). The tricky
> bit is ensuring all the steps:
> 1) store to new locations where needed
> 2) not redo things that have already been done
> 
> So this is tricky. 

It is very tricky. I don't see how you could easily achieve this isolation.
I don't think running the normal lifeycle with clovered sources is bad at
all. If the user runs:

m2 clover:on .... 

he knows he'll have clovered sources. In any case he should rebuild the full
thing with an automated build before sending to production so there's no
chance he'll make a mistake.

> I think it is achievable under the m2 lifecycle model
> (much more so than under m1 where it was all hacks), but I haven't
> completely mapped it out. I think as we work through the use cases of
> clover and some of the other reports, it will fall out nicely, but it
> might take a bit of time.

I'm open to all suggestions but it has to remain simple I think...
 
> I'm hoping to get back into lifecycle related issues this week, so we'll
> see how that pans out. Let me (and the list) know how you are
> progressing, what features you are intending to implement, how you think
> it will be invoked, etc. I'll try and spend some time documenting what
> is already there too.

I'm currently testing the modification of the source roots in order to get a
clover db when running something like:

m2 clover:on surefire:test

And I want to write a m2 project for performing functional tests of this.
This is where my other emails about testing m2 plugins comes into the
picture.

Thanks
-Vincent




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to