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...
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 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...
-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 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
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]
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...
While trying to implement what's below, I've found a snag. Here's a typical pom using clover for checking code coverage: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clover-plugin/artifactId configuration targetPercentage1%/targetPercentage /configuration executions execution idmain/id phaseverify/phase goals goalinstrument/goal goalcheck/goal /goals /execution [...] * 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: 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:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clover-plugin/artifactId
configuration
targetPercentage1%/targetPercentage
/configuration
executions
execution
idmain/id
phaseverify/phase
goals
goalinstrument/goal
goalcheck/goal
/goals
/execution
[...]
* 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...
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...
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]
