2008/11/10 Christian Schulte <[EMAIL PROTECTED]> > Stephen Connolly wrote: > > AFAIK, > > > > The execution id refers only to a specific plugin, and each execution can > > only match a specific phase... so I don't see the need to tie the > execution > > to a goal name, neither to the plugin name... > > > > What I see as bind important is if the plugin is bound to multiple phases > > and you want to configure the different phases differently... > > > > At that point I think you're left with "breaking" the id as an id.... and > > you'd end up using a wild-card type matching, e.g. > > > > <id>lifecycle:jar:*</id> > > > > or > > > > <id>lifecycle:*:compile</id> > > > > or > > > > <id>lifecycle:*:*</id> > > > > All of which are useful, and do not require a schema change, and are > rather > > unlikely to interfere with existing builds... but it feels ugly to me... > and > > yet I'm proposing it! ;-) > > > > There must not necessarily be a lifecycle in use at all. How would this > execution id match standalone executions ? E.g. > > mvn eclipse:eclipse > mvn netbeans-freeform:generate-netbeans-project > > Consider a plugin with multiple such standalone goals for which a user > needs to provide configurations per goal. Neither the lifecycle nor the > packaging plays any role here, I think. E.g. > > mvn ide:eclipse > mvn ide:netbeans-freeform > > <id>none:*:none</id> ? >
Christian, Please do not take offense, but I think that you do not understand what is being discussed/proposed. Here is my understanding: Maven has the concept of a lifecycle. Each lifecycle consists of a sequence of phases. When you invoke Maven with a specific phase as the goal, Maven will process each phase in the lifecycle upto and including the phase specified as a goal. Each phase has attached plugin executions. There are two sources for attached plugin executions. The first source is from the packaging, while the second source is those executions defined in the pom. An execution must be attached to one and only one phase. When you define an execution in the pom, you do not have to specify an id for that execution: it gets the default value of "default". Thus if you want to tweak that execution using a profile, you just omit the id and the xml schema default of "default" is used again. If you want to bind a second execution to a different phase, at that point you need to define a second id for that second execution, as an execution is bound to one and only one phase. (Note that an execution bound to a phase may invoke multiple goals, and you can bind multiple executions to the same phase) The issue being discussed is that of executions defined via the lifecycle. At present these have an id of null. (A null value is impossible to define through the pom). That the value they have is not "default" is not a bug, it's a feature. We cannot give them the value "default" _because_ the lifecycle may define multiple executions of the plugin attached to different phases. For example, the jar packaging defines two executions of the maven-compiler-plugin: one attached to the compile phase and another attached to the test-compile phase. We cannot have two executions with the same id, so therefore your proposal to use "default" is dead in the water. So, how did we get here: the use case that triggered all of this is specifying a different configuration for the maven-compiler-plugin when executed during the test-compile phase (to allow unit tests to be compiled with Java 1.5, while the main code is compiled with 1.4) This is a valid use case (and a work around of adding testSource and testTarget parameters has been implemented in the maven-compiler-plugin... but it will arrise in other cases with other plugins) So the question being asked is: "What id do we assign to executions being introduced via the packaging's lifecycle bindings?" The id cannot be "default" as we have multiple bindings of the same plugin to different phases... which is why I came up with the proposal of: lifecycle:[packaging]:[phase] and allowing * to match all of either packaging or phase. As to what about standalone: well they use the default configuration for the plugin. If you think about it, executions are attached to the lifecycle for a reason. if you just execute compiler:compile raw, you will not be able to compile as the raw execution does not give the foo plugin a chance to attach the additional source folders for the generated classes that it created. -Stephen
