On 22-May-09, at 8:44 PM, Brian Fox wrote:
I feel like this is pretty low on the list of problems to be solved,
but if
the allowed phases can be a wildcard, then I guess I'm neutral on
the idea.
I think things like pom versioning are far more pressing.
Sure, I agree. It was brought up so I commented.
On Fri, May 22, 2009 at 8:10 PM, Jason van Zyl
<jvan...@sonatype.com> wrote:
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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
