You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2006/04/05 12:57:45 UTC

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> 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>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-clover-plugin</artifactId>
>         <configuration>
>           <targetPercentage>1%</targetPercentage>
>         </configuration>
>         <executions>
>           <execution>
>             <id>main</id>
>             <phase>verify</phase>
>             <goals>
>               <goal>instrument</goal>
>               <goal>check</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:vmassol@pivolis.com]
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 
> 
> 
> 
> __________________________________________________________________________
> _
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


	

	
		
___________________________________________________________________________ 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Vincent Massol <vm...@pivolis.com>.
While trying to implement what's below, I've found a snag.

Here's a typical pom using clover for checking code coverage:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-clover-plugin</artifactId>
        <configuration>
          <targetPercentage>1%</targetPercentage>
        </configuration>
        <executions>
          <execution>
            <id>main</id>
            <phase>verify</phase>
            <goals>
              <goal>instrument</goal>
              <goal>check</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:vmassol@pivolis.com]
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


	

	
		
___________________________________________________________________________ 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Vincent Massol <vm...@pivolis.com>.

> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> 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:jdcasey1779@yahoo.com]
> >> 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:vmassol@pivolis.com]
> >>>> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> >
> >
> >
> __________________________________________________________________________
> _
> > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


	

	
		
___________________________________________________________________________ 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Brett Porter <br...@apache.org>.
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:jdcasey1779@yahoo.com]
>> 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:vmassol@pivolis.com]
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________________________ 
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Vincent Massol <vm...@pivolis.com>.
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:jdcasey1779@yahoo.com]
> 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:vmassol@pivolis.com]
> >> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


	

	
		
___________________________________________________________________________ 
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Feedback needed on clover aggregation feature I'd like to implement...

Posted by John Casey <jd...@yahoo.com>.
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:vmassol@pivolis.com]
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


RE: Feedback needed on clover aggregation feature I'd like to implement...

Posted by Vincent Massol <vm...@pivolis.com>.
Here's an update so far (see below).

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org