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
