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]
