I would be in favour of replacing @phase with @allowedPhases and
@defaultPhase
Sent from my [rhymes with myPod] ;-)
On 22 May 2009, at 20:52, Jason van Zyl <jvan...@sonatype.com> wrote:
On 22-May-09, at 3:23 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
Or if the assembly plugin is truly a utility player then have no
suggested binding. [...] I think the phase as a suggestion is
probably just confusing.
I don't think providing defaults like a default phase binding in
this case is confusing. It's just convention over configuration,
isn't it?
Changing a source directory does not change the behavior of a build.
The convention for something designed to be truly pluggable.
Changing the phase the assembly plugin alters the way it works.
There is the weirdo magic, as a case in point, where depending on
what phase you are in you might get a directory or an archive as a
resolved artifact. Then you're starting to look for files or
directories in your plugin ... so I don't think this is a case of
convention over configuration here. I think a mojo is either
designed to work doing a single thing in a single phase of the
lifecycle, or it's a utility player. Assigning a "default" phase
only to have it be changed by a user likely means the mojo has not
been tested in this case and will more likely then not cause someone
confusion or just plain not work. We could even do something like
@phase package,install if you truly think something belongs and has
been tested to run in those phases.
The default value saves one from typing and also provides a hint
(not a restriction) about the major (but not the one and only)
usage of a goal.
Hoping that we will leave some decisions to the user, not the tool...
The decisions that can be made by the user have to be options that
were tested by the developers. If the developer was truly
responsible for writing a mojo and was somehow made to incur the
cost of support then I'm willing to bet that they would limit how
that mojo was used. I think it would be fine to allow a developer to
specify all the phases the plugin is known to run in and then the
user works within the known set of viable conditions. I think we
need to be very realistic about what can be supported and I think
this ultimately benefits everyone. If a system lets you do something
then one should reasonably expect it to work. There are already
complete free-for-alls for people to use and I think we have to
consider allowing less but works exactly as advertised.
Benjamin
---------------------------------------------------------------------
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
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
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
