On 22-May-09, at 4:36 PM, John Casey wrote:
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.
You don't need a proliferation of mojos, you would specify what phases
you know to work. If you can account for a single mojo to work in
multiple phases and cover all the different logic then you have a
single mojo. My point is state what you do well, if the rest is unsure
then Maven should stop. I'm not talking about what Maven does now, I'm
talking about how to ideally stop users from stepping into a mistake.
I like the idea of a default phase and allowed phases.
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.
Coding for the lowest common denominator? How do you see a developer
of a mojo who clearly states where the mojo runs because they've
tested it and know this to be the lowest common denominator?
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).
That's if that's the case then they would have no default phase and be
allowed everywhere. If that's the case for the plugin the contract in
the mojo says that. Plugins that are found to have worthless contracts
will soon not be used by people.
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.
I think this is indicative of other problems. If there is no clear
place to put something, or moreover no clear way to order within a
phase. Again I'm not talking about what we're saddled with now in 2.x
but what the system could and should be like.
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 to, but mojos can certainly have tighter contracts and
if something is not meant for a particular lifecycle that will also be
more clear.
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.
We'll agree to disagree then.
-john
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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
