On 22-May-09, at 1:39 PM, John Casey wrote:
Jason van Zyl wrote:
On 22-May-09, at 11:29 AM, Stephen Connolly wrote:
2009/5/22 Jason van Zyl <jvan...@sonatype.com>
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.
In these cases then it's where the ambiguity needs to be resolved by
the author and you have the mojo bind to the phase where it's specific
use. So if the source assembly is a use case that has emerged then
make a subclass if only to change the phase. Or if the assembly plugin
is truly a utility player then have no suggested binding. To me it
either has a specific use case in a specific phase, or it can go
anywhere. I think the phase as a suggestion is probably just confusing.
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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
