Jason van Zyl wrote:
On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
2009/5/22 Jason van Zyl <[email protected]>
On 22-May-09, at 10:46 AM, Stephen Connolly wrote:
Then both goals are bound to the integration-test phase, as I would
expect
I think 2.x is a little lax. It should blow up and tell you that you're
trying to wire the mojo to a phase not specified in the mojo itself.
If it
is supposed to flexible wrt where it runs in the lifecycle then no phase
should be specified in the mojo. You're doing something the author of
the
mojo did not intend.
Eh, I would not agree (other than in the case of the
failsafe-maven-plugin)
A user generally wouldn't because you are never saddled with supporting
the resulting outcome. I am very much driven by the question what is
truly supportable. I want to move more toward what is definitely
supported and making extremely clear boundaries like finalizing classes,
being strict about lifecycle binding and anything else that makes it
clear where you become responsible for your use versus the community.
This is my reasoning. No user is ever going to support limiting a
behavior they use.
I (as a plugin user) might have a perfectly good reason for re-binding a
goal to a different phase...
Do you?
At that point you wander into the same situation we have with people
wanting to do anything they want. Then you combine N plugins wired to
phases other then what they intended then you've got undocumented,
unsupported use. I honestly don't think this benefits anyone. This
variance has a very real cost. If we had disallowed this to start with
then you as the user would have to talk to the author or make your own
version.
Some areas may be a little grayer then others but someone trying to bind
a mojo that is designated for the generate-sources phases to another
phase makes no sense. Every mojo should be that clear cut and if it's
not then that's a problem in and of itself.
In the case of the assembly plugin, we provide '@phase package' but this
is really more of a suggestion. If you're using dependencySets, then
it's a pretty strong suggestion, since moving it up in the lifecycle
mapping too much could mean resolving dependencies earlier in the
lifecycle than you really want to.
However, if you're doing source assemblies or something, then you can
easily bind to the validate phase in many cases without any penalty. IMO
this is a perfectly appropriate situation. We've thought about the costs
associated with moving the execution out of the package phase, and
recognize that in some cases it's no problem at all.
for example I might need to execute something
in-between and therefore shift things back a phase... ok so that
should be a
2.x problem once 3.x gets the build planning code, but I would still
think
that Maven should not bomb out just because a plugin user has re-bound
the
phase from the default phase for a goal...
+1 for Maven giving a big fat warning though
My €0.02 in any case
Noted.
-Stephen
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
---------------------------------------------------------------------
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]
