Jason van Zyl 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.
I don't think it's more intuitive to have this proliferation of new
mojos, simply to handle explicitly all the potential places where it
might be appropriate to use a particular piece of build logic. As it is
in the assembly plugin, we have five or more mojos (owing to legacy
issues) that do 99% the same thing, but they're named differently to
handle the 1% difference in logic. Actually, the 1% difference is now
accounted for almost completely in the shared code, so the 1% difference
is a legacy notion as well. Now, in your approach, I'll have to create
at least several more mojos to handle cases where people want to use the
assembly plugin in different phases. I simply cannot remove the '@phase'
annotation, because in 80% of cases the user wants to use a
dependencySet which requires dependency resolution, so providing '@phase
package' eliminates configuration (by providing a convention) for 80% of
use cases.
I think it's a mistake to enforce your assumptions about the quality of
tests and/or code in plugins. It would truly be a case of coding for the
lowest common denominator, and imposing a serious penalty on plugins
that have legitimate reasons for leaving the default + configuration in
place.
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.
I'm all for this sort of documentation, telling users where a particular
plugin is safe to run. But let's not throw the baby out with the
bathwater here. There are cases where plugins could be used almost
anywhere in the build process (especially if they're not producing
something involved in the "main line" of compiling/testing/etc. the
actual source code). And frankly, there are also cases where some builds
get pretty crowded in certain lifecycle phases, and it's helpful to get
a little creative with phase bindings in cases where something has to
happen "at some point" before something else, but it doesn't necessarily
matter when.
Of course this is a little vague, but that's the point; we cannot
possibly account for every single concrete build use case in the entire
world. We don't have the infrastructure to document them, nor do we want
to engage in the endless rounds of releases required to support that
extra, marginal use case that walks in. We need to provide a tool that
operates in a declarative way at build time, but still offers users just
enough wiggle room to fit Maven responsibly around their own needs. Is
this a balancing act? Of course it is, and not all of the resulting
builds will look like elegant masterpieces of design. But the
alternative is to tell those users, "Sorry, come back later when we
release a new version that accommodates your use case." We have to try
to do the right thing, but users absolutely must have enough rope to
hang themselves, too.
Tightening the usage of @phase will eliminate a lot of critical
flexibility here.
-john
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
