maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schulte>
Subject Re: Default plugin execution id
Date Mon, 10 Nov 2008 14:55:51 GMT
Stephen Connolly wrote:
> 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.

Agreed to that, although not explicitly stated in my mail, I admit. I
did not mean to prove you wrong. Absolutely not! It was more an "I
agree! Would this also work for standalone executions the way I asked ?"

> 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)

Until now, this information was missing to this thread. See the original
mail starting this thread.

"I'd like to be able to configure the default execution of a plugin
within an execution instead of doing it through the main plugin

> 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)

You are the only person who brought that up on this thread and I am glad
you did. However, I still think the original author was talking about
something else.

> 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.

It wasn't me proposing "default" at first! You have proven us all wrong
about that id (default, default-execution-id,
#groupId:artifactId:sequenceNumber, default-execution-compile,
default-execution-testCompile). And you presented a solution which seems
to be correct. I was already convinced by your first mail.

> 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.

Maybe I was not clear about this standalone thing. This here

mvn ide:eclipse
mvn ide:netbeans
mvn ide:eclipse ide:netbeans

is also a valid use case. There is no way to configure different goals
differently via the plugin's main configuration if these goals share the
same parameters.

Well, I admit, this mixes up different things to look like the same but
originally this thread was about having the ability to configure the
default execution as an execution element in the pom and not to be
forced to use the main configuration. This also means that it makes a
configuration per goal(s) possible what is not possible using a plugin's
main configuration!

For example: Have these two goals define a mojo parameter
"outputDirectory". If you would want to use different values per goal,
one could not do that using the plugin's main configuration and is
forced to introduce two different parameters like
"eclipseOutputDirectory" and "netbeansOutputDirectory".

As I understand things, it would become possible to have that single
"outputDirectory" parameter be configured differently per goal. Which
does not prove your solution wrong, does it ? That there is no
standalone lifecycle does not mean that there could not be one with only
a single phase all command line goals get added to automatically. Leads to:




And this would even work without such a standalone or cli lifecycle, I
think. Did I really get that completely wrong ? Anyway, thanks _a lot_
for your time and for explaining things in detail.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message