> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: jeudi 16 juin 2005 15:27
> To: Maven Developers List
> Subject: Re: [m2] Clover plugin use cases (was RE: [m2] "Verification"
> phase required?)
[snip]
> >Alternatively we could possibly make clover part of the profile. So you
> >would have a profile that builds the project with clover on, using the
> main
> >tree and another profile (for production) that builds the project without
> >clover. As the generated artifacts go in the local repository we should
> also
> >separate them according to profiles. For example if you build a jar with
> JDK
> >1.4 and with JDK 1.5 you should name them differently. Something like:
> ><artifactId>-<version>-<profilename>.<extension>.
> >
> >It sounds to me it would be a better way rather than duplicating the
> source
> >and buildt trees.
> >
> >In term of continuous build you would run the main profile often and
> then,
> >say every few builds, you would run the clover profile (or vice-versa).
> Of
> >course that means that people building your project would use the main
> >profile by default and would need to specify the extra flag on the
> command
> >line to run the clover/jcoverage/etc profile.
> >
> >The advantage would be speed. The downside would be several build
> profiles
> >that are not executed together. But that's already true for different
> JDKs,
> >etc.
> >
> >WDYT?
> >
> >
> You've lost me a bit here, it seems a bit more solution that problem.
> What are you trying to do? I don't get how clovered artifacts in the CI
> repo help anyone on the receiving end...
>
> Just for some background info, you can already do profiles per jdk and
> modify the final name. You should be able to deploy them to the repo
> with a different classifier (not in the code yet though).
Ok let me try to explain it better.
- We've agreed that we need to execute the clover goals in a separate
lifecycle and not "pollute" the main build. So ideally what we would like is
a parallel execution with a parallel target tree.
- Compiling sources twice and executing the tests twice takes time.
It struck me that maybe what want is to keep a single main execution and
target tree but that we would execute under different profiles. The main
profile would not run clover at all, it would the standard lifecycle. A
clover profile could be defined by the user whenever he wants to build the
same project but in clover mode.
Note that I'd need to read up a bit more on profiles to see whether this is
possible.
Basically I see 2 options for implementing the clover plugin:
Option 1: What we have discussed so far and we "artificially" create a
parallel target tree and compile sources/execute tests twice
Option 2: We don't do any of this. We simply have a clover profile that
would turn on clover and use the "clover" name as a classifier for produced
artifacts (so that they can cannot be mistaken with the production
artifacts).
One caveat would be that clover:check would only be called when the clover
profile build is executed but that's not too bad actually. I don't expect
people to run all the builds with clover on as it would be too long. I think
there would be 2 builds: one quick one (the main one) that produces the
production artifacts and one integration one that would perform additional
checks (like clover:check), generate the site and reports, etc.
I'm not saying option 2 should be chosen. I'd just like to quickly explore
this possibility as we have discussed the design for option 1 so far and
we've not talked about this option 2.
Is it clearer now?
Thanks
-Vincent
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
