Well now you've crossed over to http://jira.codehaus.org/browse/MNG-3203 which is a separate issue imo.
-----Original Message----- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2008 4:41 PM To: Maven Developers List Subject: Re: Default plugin execution id We need to split out the different executions somehow. If we use a sequence number: 1. How do I deterministically know what sequence number to use? 2. What happens when a newer version of the lifecycle introduces an earlier execution? On my count, that leaves a sequence number nearly dead If we use the goal name: 1. What happens if the goal appears more than once? (OK, so coming from the lifecycle, this is likely not too big an issue as the lifecycle will not allow differential configuration of the same goal executed twice... but it may be that the mojo infers things from the reactor / or updates to the Maven project... for example we may want to enforce some things at the start and then enforce more things at a later phase) The only thing that we know occurs only once is the phase... The down-side of the phase is multiple executions in the one phase would share the same configuration. -Stephen 2008/11/10 Brian E. Fox <[EMAIL PROTECTED]> > 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]
