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]
