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]
