RE: Feedback needed on clover aggregation feature I'd like to implement...
> -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: samedi 8 avril 2006 16:15 > To: Maven Developers List > Subject: Re: Feedback needed on clover aggregation feature I'd like to > implement... > > It doesn't sound right, classifier is the right one. Relying on a > packaging plugin having the 'classifier' configuration element is too > fragile in either case, even if they all had it. > > So if I understand, you are forking the lifecycle (should it be package > instead of install?), I need install because I need to install the clovered artifacts for other modules to use them. > passing in the configuration to ensure the second > run is all done automatically? yes > This is definitely a use case to keep in mind for lifecycle > improvements. We need to more carefully consider consistency around > packaging - it should be declarative from the POM as well so that the > output file can be found reliably without known the packaging plugin > internals. > > As for this case, it's ugly, but I'd suggest building it to the normal > location (package, not install), then grab the executedProject after > forking, rename it to add the classifier to the filename and attach it > to the main artifact with the classifier. I assume that the > build/install of the main artifact occurs after this closer step (which > would be in test). Ok, I've done the following: Artifact oldArtifact = getProject().getArtifact(); Artifact newArtifact = this.artifactFactory.createArtifactWithClassifier( oldArtifact.getGroupId(), oldArtifact.getArtifactId(), oldArtifact.getVersion(), oldArtifact.getType(), "clover" ); getProject().setArtifact( newArtifact ); getProject().getBuild().setFinalName( getProject().getArtifactId() + "-" + getProject().getVersion() + "-clover"); Seems to be working fine. Thanks -Vincent > Vincent Massol wrote: > > Ok here's some feedback on this. > > > > I've succeeded in implementing it. However I've found that not all > plugins > > support classifiers (the ear plugin does not for example). As a > consequence > > some main artifacts are generated with clovered stuff in them. That's > wrong > > as clovered stuff should not be mixed with main artifacts. > > > > As it'll never be possible to ensure that all plugins used within the > forked > > clover lifecycle support classifiers, I'm going to modify the clover > plugin > > algorithm not to use classifiers... > > > > Instead I'll simply try appending "-clover" to the main artifact's > > artifactId. I haven't fully thought it out so I may discover other > issues > > along the way. > > > > Let me know if you think I'm going in the right direction... > > > > Thanks > > -Vincent > > > >> -Original Message- > >> From: John Casey [mailto:[EMAIL PROTECTED] > >> Sent: mercredi 5 avril 2006 20:47 > >> To: Maven Developers List > >> Subject: Re: Feedback needed on clover aggregation feature I'd like to > >> implement... > >> > >> You'd need an ArtifactFactory and an ArtifactResolver, along with the > >> repository list and the local repository...I think that's it. > >> > >> Once you have these, you can use the original artifact to create a new > >> one with the "clover" classifier, then feed that into the > >> ArtifactResolver, along with the repositories mentioned above. > >> > >> I'm currently doing this to locate source archives for the builds of a > >> client... > >> > >> Let me know if you have trouble. > >> > >> -john > >> > >> Vincent Massol wrote: > >>> Here's an update so far (see below). > >>> > >>>> -Original Message- > >>>> From: Vincent Massol [mailto:[EMAIL PROTECTED] > >>>> Sent: mercredi 5 avril 2006 12:58 > >>>> To: 'Maven Developers List' > >>>> Subject: Feedback needed on clover aggregation feature I'd like to > >>>> implement... > >>>> > >>>> Hi, > >>>> > >>>> I've just realized that there's work to be done on the clover plugin > if > >> we > >>>> want it to support aggregated clover reports. By aggregated reports, > I > >>>> mean > >>>> getting a single report for all modules. Right now this is possible > but > >>>> each > >&
Re: Feedback needed on clover aggregation feature I'd like to implement...
It doesn't sound right, classifier is the right one. Relying on a packaging plugin having the 'classifier' configuration element is too fragile in either case, even if they all had it. So if I understand, you are forking the lifecycle (should it be package instead of install?), passing in the configuration to ensure the second run is all done automatically? This is definitely a use case to keep in mind for lifecycle improvements. We need to more carefully consider consistency around packaging - it should be declarative from the POM as well so that the output file can be found reliably without known the packaging plugin internals. As for this case, it's ugly, but I'd suggest building it to the normal location (package, not install), then grab the executedProject after forking, rename it to add the classifier to the filename and attach it to the main artifact with the classifier. I assume that the build/install of the main artifact occurs after this closer step (which would be in test). Is that ok? - Brett Vincent Massol wrote: > Ok here's some feedback on this. > > I've succeeded in implementing it. However I've found that not all plugins > support classifiers (the ear plugin does not for example). As a consequence > some main artifacts are generated with clovered stuff in them. That's wrong > as clovered stuff should not be mixed with main artifacts. > > As it'll never be possible to ensure that all plugins used within the forked > clover lifecycle support classifiers, I'm going to modify the clover plugin > algorithm not to use classifiers... > > Instead I'll simply try appending "-clover" to the main artifact's > artifactId. I haven't fully thought it out so I may discover other issues > along the way. > > Let me know if you think I'm going in the right direction... > > Thanks > -Vincent > >> -----Original Message----- >> From: John Casey [mailto:[EMAIL PROTECTED] >> Sent: mercredi 5 avril 2006 20:47 >> To: Maven Developers List >> Subject: Re: Feedback needed on clover aggregation feature I'd like to >> implement... >> >> You'd need an ArtifactFactory and an ArtifactResolver, along with the >> repository list and the local repository...I think that's it. >> >> Once you have these, you can use the original artifact to create a new >> one with the "clover" classifier, then feed that into the >> ArtifactResolver, along with the repositories mentioned above. >> >> I'm currently doing this to locate source archives for the builds of a >> client... >> >> Let me know if you have trouble. >> >> -john >> >> Vincent Massol wrote: >>> Here's an update so far (see below). >>> >>>> -Original Message- >>>> From: Vincent Massol [mailto:[EMAIL PROTECTED] >>>> Sent: mercredi 5 avril 2006 12:58 >>>> To: 'Maven Developers List' >>>> Subject: Feedback needed on clover aggregation feature I'd like to >>>> implement... >>>> >>>> Hi, >>>> >>>> I've just realized that there's work to be done on the clover plugin if >> we >>>> want it to support aggregated clover reports. By aggregated reports, I >>>> mean >>>> getting a single report for all modules. Right now this is possible but >>>> each >>>> module will only contribute coverage for its own code. I'd like that >>>> coverage generated by a module on some other module's code also gets >>>> counted. >>>> >>>> For this I'm planning to try implementing the following: >>>> >>>> * Modify clover:instrument so that the forked lifecycle extends till >> the >>>> install phase >>> Done. >>> >>> BTW we may need 2 goals: instrument and instrumentAndInstall so that >>> instrument goes till the "test" phase while instrumentAndInstall goes >> till >>> the "install" phase. >>> >>>> * Create an internal clover mojo bound to the install phase that will >>>> created a clovered version of the project's artifact as an attached >>>> artifact >>>> (classifier = "clover"). >>> Not needed actually. >>> >>>> * Handle the different type of packaging. For example for a WAR >> packaging, >>>> add the clover jar to the attached clovered WAR, etc. >>> Done automatically as we're adding the clover dep to the
RE: Feedback needed on clover aggregation feature I'd like to implement...
Ok here's some feedback on this. I've succeeded in implementing it. However I've found that not all plugins support classifiers (the ear plugin does not for example). As a consequence some main artifacts are generated with clovered stuff in them. That's wrong as clovered stuff should not be mixed with main artifacts. As it'll never be possible to ensure that all plugins used within the forked clover lifecycle support classifiers, I'm going to modify the clover plugin algorithm not to use classifiers... Instead I'll simply try appending "-clover" to the main artifact's artifactId. I haven't fully thought it out so I may discover other issues along the way. Let me know if you think I'm going in the right direction... Thanks -Vincent > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: mercredi 5 avril 2006 20:47 > To: Maven Developers List > Subject: Re: Feedback needed on clover aggregation feature I'd like to > implement... > > You'd need an ArtifactFactory and an ArtifactResolver, along with the > repository list and the local repository...I think that's it. > > Once you have these, you can use the original artifact to create a new > one with the "clover" classifier, then feed that into the > ArtifactResolver, along with the repositories mentioned above. > > I'm currently doing this to locate source archives for the builds of a > client... > > Let me know if you have trouble. > > -john > > Vincent Massol wrote: > > Here's an update so far (see below). > > > >> -Original Message- > >> From: Vincent Massol [mailto:[EMAIL PROTECTED] > >> Sent: mercredi 5 avril 2006 12:58 > >> To: 'Maven Developers List' > >> Subject: Feedback needed on clover aggregation feature I'd like to > >> implement... > >> > >> Hi, > >> > >> I've just realized that there's work to be done on the clover plugin if > we > >> want it to support aggregated clover reports. By aggregated reports, I > >> mean > >> getting a single report for all modules. Right now this is possible but > >> each > >> module will only contribute coverage for its own code. I'd like that > >> coverage generated by a module on some other module's code also gets > >> counted. > >> > >> For this I'm planning to try implementing the following: > >> > >> * Modify clover:instrument so that the forked lifecycle extends till > the > >> install phase > > > > Done. > > > > BTW we may need 2 goals: instrument and instrumentAndInstall so that > > instrument goes till the "test" phase while instrumentAndInstall goes > till > > the "install" phase. > > > >> * Create an internal clover mojo bound to the install phase that will > >> created a clovered version of the project's artifact as an attached > >> artifact > >> (classifier = "clover"). > > > > Not needed actually. > > > >> * Handle the different type of packaging. For example for a WAR > packaging, > >> add the clover jar to the attached clovered WAR, etc. > > > > Done automatically as we're adding the clover dep to the list of deps in > the > > instrument mojo... > > > >> * Modify the clover:instrumentInternal so that for any dependency > >> artifact, > >> it looks for the clovered version in the repo and adds it instead of > the > >> non-clovered version. > > > > This is where I'm stuck right now. Not sure how to do this yet. If > anyone > > knows how to find an attached artifact once you have the main artifact > > object that would be nice. > > > >> As this is pretty involved I'd like to be sure this is the right thing > to > >> do. > > > > Thanks > > -Vincent > > > > > > > > > > > > > > > __ > _ > > Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les > tarifs exceptionnels pour appeler la France et l'international. > > Téléchargez sur http://fr.messenger.yahoo.com > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback needed on clover aggregation feature I'd like to implement...
You'd need an ArtifactFactory and an ArtifactResolver, along with the repository list and the local repository...I think that's it. Once you have these, you can use the original artifact to create a new one with the "clover" classifier, then feed that into the ArtifactResolver, along with the repositories mentioned above. I'm currently doing this to locate source archives for the builds of a client... Let me know if you have trouble. -john Vincent Massol wrote: Here's an update so far (see below). -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: mercredi 5 avril 2006 12:58 To: 'Maven Developers List' Subject: Feedback needed on clover aggregation feature I'd like to implement... Hi, I've just realized that there's work to be done on the clover plugin if we want it to support aggregated clover reports. By aggregated reports, I mean getting a single report for all modules. Right now this is possible but each module will only contribute coverage for its own code. I'd like that coverage generated by a module on some other module's code also gets counted. For this I'm planning to try implementing the following: * Modify clover:instrument so that the forked lifecycle extends till the install phase Done. BTW we may need 2 goals: instrument and instrumentAndInstall so that instrument goes till the "test" phase while instrumentAndInstall goes till the "install" phase. * Create an internal clover mojo bound to the install phase that will created a clovered version of the project's artifact as an attached artifact (classifier = "clover"). Not needed actually. * Handle the different type of packaging. For example for a WAR packaging, add the clover jar to the attached clovered WAR, etc. Done automatically as we're adding the clover dep to the list of deps in the instrument mojo... * Modify the clover:instrumentInternal so that for any dependency artifact, it looks for the clovered version in the repo and adds it instead of the non-clovered version. This is where I'm stuck right now. Not sure how to do this yet. If anyone knows how to find an attached artifact once you have the main artifact object that would be nice. As this is pretty involved I'd like to be sure this is the right thing to do. Thanks -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback needed on clover aggregation feature I'd like to implement...
Here's an update so far (see below). > -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: mercredi 5 avril 2006 12:58 > To: 'Maven Developers List' > Subject: Feedback needed on clover aggregation feature I'd like to > implement... > > Hi, > > I've just realized that there's work to be done on the clover plugin if we > want it to support aggregated clover reports. By aggregated reports, I > mean > getting a single report for all modules. Right now this is possible but > each > module will only contribute coverage for its own code. I'd like that > coverage generated by a module on some other module's code also gets > counted. > > For this I'm planning to try implementing the following: > > * Modify clover:instrument so that the forked lifecycle extends till the > install phase Done. BTW we may need 2 goals: instrument and instrumentAndInstall so that instrument goes till the "test" phase while instrumentAndInstall goes till the "install" phase. > * Create an internal clover mojo bound to the install phase that will > created a clovered version of the project's artifact as an attached > artifact > (classifier = "clover"). Not needed actually. > > * Handle the different type of packaging. For example for a WAR packaging, > add the clover jar to the attached clovered WAR, etc. Done automatically as we're adding the clover dep to the list of deps in the instrument mojo... > * Modify the clover:instrumentInternal so that for any dependency > artifact, > it looks for the clovered version in the repo and adds it instead of the > non-clovered version. This is where I'm stuck right now. Not sure how to do this yet. If anyone knows how to find an attached artifact once you have the main artifact object that would be nice. > As this is pretty involved I'd like to be sure this is the right thing to > do. Thanks -Vincent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback needed on clover aggregation feature I'd like to implement...
> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: mercredi 5 avril 2006 17:51
> To: 'Maven Developers List'
> Subject: RE: Feedback needed on clover aggregation feature I'd like to
> implement...
>
> While trying to implement what's below, I've found a snag.
>
> Here's a typical pom using clover for checking code coverage:
>
>
> org.apache.maven.plugins
> maven-clover-plugin
>
> 1%
>
>
>
> main
> verify
>
> instrument
> check
>
>
> [...]
>
> * I've modified the clover:instrument mojo to fork a lifecycle till the
> install phase (it was forking till test previously) in order to install
> the
> generated clovered artifact to the local repo.
>
> * However, as the verify phase is happening before the install phase this
> is
> now triggering the clover:check goal *inside* the forked lifecycle and
> it's
> executed as second time in the main lifecycle. I need to prevent
> clover:check from executing inside the forked lifecyce.
>
> Question: is there a way not to execute clover:check inside the forked
> lifecycle? I can't find a solution out of this apart from binding
> clover:check to a later phase but then the only phase after install is
> deploy which doesn't really make sense...
For now I've simply done an ugly hack by doing some check:
public void execute()
throws MojoExecutionException
{
if ( !isInCloverForkedLifecycle() )
{
[...]
}
}
private boolean isInCloverForkedLifecycle()
{
// We know we're in the forked lifecycle if the output directory is
// set to target/clover...
// TODO: Not perfect, need to find a better way. This is a hack!
return getProject().getBuild().getDirectory().endsWith( "clover" );
}
If anyone has a better idea, please shoot!
Thanks
-Vincent
>
> Thanks
> -Vincent
>
> > -Original Message-
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: mercredi 5 avril 2006 12:58
> > To: 'Maven Developers List'
> > Subject: Feedback needed on clover aggregation feature I'd like to
> > implement...
> >
> > Hi,
> >
> > I've just realized that there's work to be done on the clover plugin if
> we
> > want it to support aggregated clover reports. By aggregated reports, I
> > mean
> > getting a single report for all modules. Right now this is possible but
> > each
> > module will only contribute coverage for its own code. I'd like that
> > coverage generated by a module on some other module's code also gets
> > counted.
> >
> > For this I'm planning to try implementing the following:
> >
> > * Modify clover:instrument so that the forked lifecycle extends till the
> > install phase
> >
> > * Create an internal clover mojo bound to the install phase that will
> > created a clovered version of the project's artifact as an attached
> > artifact
> > (classifier = "clover").
> >
> > * Handle the different type of packaging. For example for a WAR
> packaging,
> > add the clover jar to the attached clovered WAR, etc.
> >
> > * Modify the clover:instrumentInternal so that for any dependency
> > artifact,
> > it looks for the clovered version in the repo and adds it instead of the
> > non-clovered version.
> >
> > As this is pretty involved I'd like to be sure this is the right thing
> to
> > do.
> >
> > Thanks for any feedback!
> > -Vincdent
> >
> >
> >
> >
> >
> >
> >
> __
> > _
> > Nouveau : tiliphonez moins cher avec Yahoo! Messenger ! Dicouvez les
> > tarifs exceptionnels pour appeler la France et l'international.
> > Tilichargez sur http://fr.messenger.yahoo.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
> __
> _
> Nouveau : tiliphonez moins cher avec Yahoo! Messenger ! Dicouvez les
> tarifs exceptionnels pour appeler la France et l'international.
> Tilichargez sur http://fr.messenger.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
___
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs
exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback needed on clover aggregation feature I'd like to implement...
While trying to implement what's below, I've found a snag. Here's a typical pom using clover for checking code coverage: org.apache.maven.plugins maven-clover-plugin 1% main verify instrument check [...] * I've modified the clover:instrument mojo to fork a lifecycle till the install phase (it was forking till test previously) in order to install the generated clovered artifact to the local repo. * However, as the verify phase is happening before the install phase this is now triggering the clover:check goal *inside* the forked lifecycle and it's executed as second time in the main lifecycle. I need to prevent clover:check from executing inside the forked lifecyce. Question: is there a way not to execute clover:check inside the forked lifecycle? I can't find a solution out of this apart from binding clover:check to a later phase but then the only phase after install is deploy which doesn't really make sense... Thanks -Vincent > -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: mercredi 5 avril 2006 12:58 > To: 'Maven Developers List' > Subject: Feedback needed on clover aggregation feature I'd like to > implement... > > Hi, > > I've just realized that there's work to be done on the clover plugin if we > want it to support aggregated clover reports. By aggregated reports, I > mean > getting a single report for all modules. Right now this is possible but > each > module will only contribute coverage for its own code. I'd like that > coverage generated by a module on some other module's code also gets > counted. > > For this I'm planning to try implementing the following: > > * Modify clover:instrument so that the forked lifecycle extends till the > install phase > > * Create an internal clover mojo bound to the install phase that will > created a clovered version of the project's artifact as an attached > artifact > (classifier = "clover"). > > * Handle the different type of packaging. For example for a WAR packaging, > add the clover jar to the attached clovered WAR, etc. > > * Modify the clover:instrumentInternal so that for any dependency > artifact, > it looks for the clovered version in the repo and adds it instead of the > non-clovered version. > > As this is pretty involved I'd like to be sure this is the right thing to > do. > > Thanks for any feedback! > -Vincdent > > > > > > > __ > _ > Nouveau : tiliphonez moins cher avec Yahoo! Messenger ! Dicouvez les > tarifs exceptionnels pour appeler la France et l'international. > Tilichargez sur http://fr.messenger.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback needed on clover aggregation feature I'd like to implement...
> -Original Message- > From: Mike Perham [mailto:[EMAIL PROTECTED] > Sent: mercredi 5 avril 2006 15:52 > To: Maven Developers List > Subject: RE: Feedback needed on clover aggregation feature I'd like to > implement... > > Wow, that sounds cool. We're already blown away by the aggregated report. > > On second thought, I think that feature, while nifty, is not high > priority. In fact I believe we would disable it if possible. A module's > unit tests should exercise its code as much as possible and not rely on > other modules to exercise it. That's where the Clover report is useful - > to point out coverage weaknesses in the unit tests and this feature would > mask those weaknesses somewhat. Mike, you're very right when it comes to unit tests. However this is for functional tests. For unit test what already exist is sufficient as you mention. For example in Cargo I have lots of functional tests and those test exercise the code. It's fair to count these tests when we compute the global test coverage because functional tests are exercising code. Thanks -Vincent > -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 05, 2006 5:58 AM > To: 'Maven Developers List' > Subject: Feedback needed on clover aggregation feature I'd like to > implement... > > Hi, > > I've just realized that there's work to be done on the clover plugin if we > want it to support aggregated clover reports. By aggregated reports, I > mean getting a single report for all modules. Right now this is possible > but each module will only contribute coverage for its own code. I'd like > that coverage generated by a module on some other module's code also gets > counted. > > For this I'm planning to try implementing the following: > > * Modify clover:instrument so that the forked lifecycle extends till the > install phase > > * Create an internal clover mojo bound to the install phase that will > created a clovered version of the project's artifact as an attached > artifact (classifier = "clover"). > > * Handle the different type of packaging. For example for a WAR packaging, > add the clover jar to the attached clovered WAR, etc. > > * Modify the clover:instrumentInternal so that for any dependency > artifact, it looks for the clovered version in the repo and adds it > instead of the non-clovered version. > > As this is pretty involved I'd like to be sure this is the right thing to > do. > > Thanks for any feedback! > -Vincdent > > > > > > > __ > _ > Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les > tarifs exceptionnels pour appeler la France et l'international. > Téléchargez sur http://fr.messenger.yahoo.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Feedback needed on clover aggregation feature I'd like to implement...
Wow, that sounds cool. We're already blown away by the aggregated report. On second thought, I think that feature, while nifty, is not high priority. In fact I believe we would disable it if possible. A module's unit tests should exercise its code as much as possible and not rely on other modules to exercise it. That's where the Clover report is useful - to point out coverage weaknesses in the unit tests and this feature would mask those weaknesses somewhat. -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 05, 2006 5:58 AM To: 'Maven Developers List' Subject: Feedback needed on clover aggregation feature I'd like to implement... Hi, I've just realized that there's work to be done on the clover plugin if we want it to support aggregated clover reports. By aggregated reports, I mean getting a single report for all modules. Right now this is possible but each module will only contribute coverage for its own code. I'd like that coverage generated by a module on some other module's code also gets counted. For this I'm planning to try implementing the following: * Modify clover:instrument so that the forked lifecycle extends till the install phase * Create an internal clover mojo bound to the install phase that will created a clovered version of the project's artifact as an attached artifact (classifier = "clover"). * Handle the different type of packaging. For example for a WAR packaging, add the clover jar to the attached clovered WAR, etc. * Modify the clover:instrumentInternal so that for any dependency artifact, it looks for the clovered version in the repo and adds it instead of the non-clovered version. As this is pretty involved I'd like to be sure this is the right thing to do. Thanks for any feedback! -Vincdent ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
