> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: jeudi 16 juin 2005 15:02
> To: Maven Developers List
> Subject: Re: final lifecycle doc - users perspective. Please review.
[snip]
> >1/ "[...]Note that adding the plugin on its own is not enough information
> -
> >you must also specify the goals you want run as part of your build.[...]"
> >
> >Is that so? In my sample test that uses my clover plugin, I haven't
> defined
> >a goal and it is still called when executing "m2 install" for example.
> >
> >
> The doc is how it should be, not how it is :) The current lifecycle
> implementation is much more complicated than it needs to be.
> I don't (any longer) feel binding a whole plugin makes sense - do you
> have a use case where it does, or just wondering?
Just wondering and verifying what is said in the doc is correct.
[snip]
> >2/ "[...]The goals that are configured will be added to the goals already
> >bound to the lifecycle from the packaging selected.[...]"
> >
> >Could you please explain what will be the order when several goals are
> bound
> >to the same phase? Will the ones in the POM be executed *after* the one
> in
> >the lifecycle being used and in the order they are defined in the POM?
> >
> >
> Good point. Lifecycle, then parent, then current, then profile is the
> order, I think. Order in POM wherever appropriate, yes.
Ok thanks. This should be added to the doc. So that means there's no
possibility of putting one's own goal before another one bound to the same
phase unless you define a custom lifecycle and explicitely bind it before.
That's fine I think but would need to be explained in the doc too I think.
> >3/ "[...]Additionally, even goals participating in the build lifecycle
> might
> >need to perform a task with different parameters to what was already
> >used,[...]"
> >
> >As the executePhase is specified as an annotation how could you set those
> >different parameters *before* executePhase is called? Would you need in
> that
> >case to have a custom lifecycle.xml file and specify them there?
> >
> >
> Yep. Or, you may have modified it with a previous goal.
But if you are in a previous goal you don't have access to the newly spawn
lifecycle so you can't modify the new MavenProject object. It seems the only
solution is a custom lifecycle file.
> >4/ "[...]But, it would also need to add some configuration and bind the
> >clover:compiler goal to the generate-sources phase.[...]"
> >
> >Hmm... There's no clover:compiler goal because Clover is not providing
> any
> >compiler. I wanted to reuse the compiler:compile goal rather than to
> write a
> >clover:compiler goal.
> >
> >
> No problem, will just adjust the doc later. So it is clover:generate?
Well there is clover:instrument for now (I could rename it to
clover:generate if it sounds more standard although instrument has more
meaning I think). But the issue is not so much the name as the user case you
are describing in the document. I'm offline right now so I can't check it
but I seem to recall that you example made sense only if there were a
clover:compiler goal...
[snip]
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]
