Vincent Massol wrote:
Hi Brett,
I've read it. It's very good and crystal clear. However I have a few
questions:
Thanks
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?
It could be problematic, especially if any goals are listed (do you bind
just those then, or the whole plugin?), or otherwise if there is an
inheritence scenario it is hard to tell what might happen (adding a goal
in the parent might turn of a whole plugin down the chain)..
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.
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.
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?
Also, would you have thoughts on my previous mail on clover design? I'm keen
to hear what you think on the parallel build execution vs having Clover as a
profile...
Oh, I remember there were questions in there. I'll take a look straight
away.
Thanks a lot. That's a great document that helped me fit everything
together.
Great!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
