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 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.
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]
>
>
