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] > > > > > > > ___________________________________________________________________________ > 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]
