Jason van Zyl wrote:
We could also just go simple and spit out an XML document with all the
plugins in the default lifcycle with versions and configurations.
[...] I'm sure you can see the lack of symmetry in
having to synthesize execution elements for the model builder to
consume. They should just be there in full form.
Kind of a mixin, sounds logical to me. Providing the default lifecycle
executions in explicit form for consumption by the model builder should also
a) Make the effective POM more expressive, i.e. with "mvn
help:effective-pom" users would actually see what plugins execute by
default, reducing some black-magic.
b) Ease configuration of default executions (MNG-3203). One issue we
discussed in some length back ago was how to automatically derive a
default execution id for those implicit executions [0]. But if we
explicitly/manually define the lifecycle executions, a human (lifecycle
developer) can carefully choose safe and user-friendly executions ids.
The only downside of this approach that I see are executions with two or
more goals which share some parameters with the same name but different
default-values/expressions, e.g.
<execution>
<goals>
<goal>foo</goal>
<goal>bar</goal>
</goals>
</execution>
and in FooMojo
/**
* @parameter default-value="foo"
*/
private String someParameter;
while in BarMojo
/**
* @parameter default-value="bar"
*/
private String someParameter;
AFAIK, the plugin manager in 2.x has no problems with this clash as it
processes these default-values lately when configuring a single mojo
just before its execution. However, when we pull the configuration from
several mojo descriptors into the one <configuration> section of an
<execution>, we need to decide how to handle this case (first-wins,
last-wins, error, etc.)
- the model builder should stand-alone to build fully inherited/interpolated
models
- the project builder should bring in any runtime information in the form of properties, and really should be a very thin layer over the model builder
I assume this means we don't have the model builder interpolate once and
then the project builder again with new properties. Otherwise, the first
interpolation would wipe out any chance for runtime informatin like
CLI/system/exection properties to override say stuff from the POM's
<properties> section.
Benjamin
[0] http://docs.codehaus.org/display/MAVENUSER/Default+Plugin+Execution+IDs
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
