What if I do
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-lifecycle:testCompile</id>
<phase>pre-integration-test</phase>
</execution>
2008/11/10 Brian E. Fox <[EMAIL PROTECTED]>
> Again, why? It's not possible now so it's obviously working for most
> cases today.
>
> -----Original Message-----
> From: Stephen Connolly [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 10, 2008 4:27 PM
> To: Maven Developers List
> Cc: Maven Developers List
> Subject: Re: Default plugin execution id
>
> well you need to separate out the executions by phase in case somebody
> decided to change the phase specified in the execution
>
> Sent from my iPod
>
> On 10 Nov 2008, at 21:29, "Brian E. Fox" <[EMAIL PROTECTED]>
> wrote:
>
> > 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]
> >
>
> ---------------------------------------------------------------------
> 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]
>
>
