I don't see how phase is really needed. It applies to only two plugins
that I can think of, compiler and resources, and this is a bigger
problem for a 3.x timeframe. I think that something simple can cover
90%
of the cases and be doable in 2.x
-----Original Message-----
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2008 4:05 PM
To: Maven Developers List
Subject: Re: Default plugin execution id
Yes, you're right, I think this is getting more complicated that it
needs to be.
Either of these is fine with me:
default-lifecycle:goal
or
default-lifecycle:phase
Either of them should be pretty easy to implement, and pretty unlikely
to cause
any new problems. If we just use default by itself, then we don't
resolve
compile/testCompile or other similar situations.
Brian E. Fox wrote:
I think we've gone way off the rails here. I see there's a proposal
but
haven't reviewed it yet.
The first portion of this discussion was rather small in scope:
Currently default executions of plugins have a null id. The null is
used
to indicate the default config for a plugin across all executions AND
is
used for lifecycle bound or plugins run on the cli. I think we simply
should start by separating this. Keep default to replace the current
null values for the global plugin configuration as it applies across
all
executions. Then define an id for the lifecycle and cli invocations
to
be applied to tweak the values as needed (but keeping default to
apply
across all). Going beyond this into multifaceted ids for packages etc
is
far too complicated imo.
-----Original Message-----
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2008 3:44 PM
To: Maven Developers List
Subject: Re: Default plugin execution id
Stephen Connolly wrote:
2008/11/10 Paul Gier <[EMAIL PROTECTED]>
What about adding new syntax to the goal string? So that from the
command
line you could write something like this to refer to specific
execution
configs:
mvn eclipse:eclipse{execution-1}
or
mvn eclipse:eclipse{execution-2}
How would that interact with the lifecycle?
If I define execution-1 as attached to the compile phase, does that
mean
that Maven will execute all phases upto compile and then just
execute
eclipse:eclipse, or is it just executing eclipse:eclipse and
ignoring
any
plugins that are attached to prior phases? (With the side effect
that
I'd
loose the information of the extra attached source directories)
The more I think about it, calling out a specific execution *that
has
been
attached to a specific phase* is a bad bad pattern, and it's a good
thing
that Maven does not let you do that.
If you need to do a pile of every-so-often tasks I'd define them in
profiles
with each profile attaching the plugins to the requisite phases and
defining
the defaultGoals to the highest phase necessary.
The curly braces already seem to be associated with execution ids
in
maven's logging output. This would mean that components.xml file
in
maven
core could be changed to provide execution IDs for each plugin that
is
executed, but probably no one wants to manually update this all the
time.
IMO the wildcard syntax is more than what is needed, and will make
the pom
a little less readable. The choice should be configure all
executions or
just one, otherwise it starts getting too complicated.
After looking into the current behavior a little more, it is
possible
to
execute the same plugin goal twice in the same phase. So I think
all
the
naming schemes proposed except maybe Brett's
(groupId:artifactId:sequenceNumber) could run into conflicts in the
future.
But if we include a sequence number, then what happens if you add
another
execution of an existing plugin to the lifecycle? Do all the
sequence
numbers have to increment to make room?
Plus sequence number is non-deterministic. Also, you are
forgetting... this
is not the id of executions *defined within the pom* but it's the id
of
executions *defined by either the lifecycle or the plugin's mojo
bindings*
I don't see how a mojo's descriptor can bind to any more than one
phase, so
I guess the only thing preventing uniqueness is if the lifecycle can
invoke
the same goal multiple times in the same phase... but hang on, how
is
that a
problem if we say that the execution is per phase (unless you want
to
configure the different multiple executions differentially....
sounds
like
you're writing a severe hack)
I just said that sequence numbers are the only way suggested that
completely
avoid id conflicts, but you're right it has other problems.
I don't think it's a severe hack to have two executions for the same
plugin goal
in the same phase. For example, let's say I want to generate three
jar
files
with different manifests during the package phase. I need to call
the
assembly
or jar plugin three times with different configurations. I'm just
saying it's
possible to have this scenario even in a default lifecycle, so there
is
a small
possibility of a name conflict even if we use something like
lifecycle-<packaging>-<phase>-<plugin>-<goal>
I think if we add the goal name to the execution like Benjamin
suggested,
we will be unlikely to run into conflicts. So I would prefer
something
like:
default-lifecycle-compile
default-lifecycle-testCompile
No, what if I bind compile goal to the compile phase and
process-classes?
Now I have an execution that is bound to two phases (not allowed) or
two
executions with the same id (not allowed)
I'm sorry, but I don't see how you can exclude the phase from the
execution's id...
And given that phases consist of names separated by -, it seems
confusing to
name them with - as a separator.
Adding the phase to the ID doesn't prevent name conflicts, since you
can
have
the same goal twice in the same phase. I would guess it's actually
be
more
common to have a goal twice in the same phase vs. in different
phases.
So I
think the goal name is a better qualifier than the phase.
Now I don't mind if we do
default-lifecycle:compile
default-lifecycle:test-compile
or
lifecycle:compile
lifecycle:test-compile
or
lifecycle:jar:compile
lifecycle:jar:test-compile
or even use a different separator ('/' anyone?)
The only advantage of specifying the packaging type is if you have a
common
root pom. Wildcards only become really important if you use
packaging
in
the id, but there is still the issue of what if I need to specify
something
for all executions (but keep the defaults outside of an execution
different
for when executing goals directly from the command line)
I can live without wildcards.
Sequence numbers are either non-deterministic, or will end up having
a
1:1
mapping with each phase, so why not just use the phase. Goal is
non-unique,
and has the problem of multiple executions, and we can likely get
away
with
just phase anyway.
When building, this logs to the command line like this:
[INFO] [compiler:compile {execution: default-lifecycle-compile}]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
