On 4-May-09, at 7:50 AM, Benjamin Bentmann wrote:
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.
Yes, more what you see is what you get. It would also make joining the
elements easier because we won't have to do this synthesis along the
way.
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.)
Here we should just get more explicit and probably say one goal per
execution with its own configuration to just avoid any problems forever.
- 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.
Right, this should only happen once. The project builder should really
do nothing but introduce runtime values for interpolation.
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
A language that doesn’t affect the way you think about programming is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
