I still think that the id has to include the phase that the execution is bound to. I'm not tied to specification of the packaging, but I do think that the phase (given that an execution is associated with one and only one phase) has to be part of the id for *lifecycle introduced* executions.
-Stephen 2008/11/10 Brian E. Fox <[EMAIL PROTECTED]> > 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] > >
