Hi Benjamin,
Sorry for the delayed reply.
On 11/01/2009, at 2:06 PM, Benjamin Bentmann wrote:
IMHO, there should be no way to override model values to ensure a
reliable degree of independence from the environment. Hence I
suggest the handle model values and the <properties> section as
independent interpolation sources, i.e.
+1 (even better - produce an error if you try so there can be no
confusion)
The first "B" in the Maven 2.x answer results from the interpolator
stripping the "project.|pom." prefix from "project.prop" when
querying the <properties> section.
IMHO, here is Maven 3.x making a nicer job. "Nice" here means more
intuitive and more consistent. With "consistent" I refer to the
behavior of the PluginParameterExpressionEvaluator that does not
strip any prefixes from expressions when resolving them from the
<properties> section.
If we agree that the current Maven 2.x way to handle an expression
that is prefixed with project.|pom. but doesn't match a model value
is odd, can we change/fix this behavior for Maven 2.1.x and even
Maven 2.0.x?
I would say not 2.0.x, but I think it makes sense for 2.1.x. I believe
we could drop the "stripped" syntax already and handle it with errors
when used.
P.S.: For those that sill wonder what YAPII means: "Yet Another POM
Interpolation Issue". Sorry, but I was in strange mood.
Oddly enough, I got it straight off :)
On 16/01/2009, at 2:50 AM, Benjamin Bentmann wrote:
So far about POM interpolation. For plugin config interpolation
however, the precedence realized by the
PluginParameterExpressionEvaluator in Maven 2.x is to first consult
the model's <properties> section and then CLI/execution properties,
i.e. this is the reverse order used for interpolation.
This was apparently fixed in r572229 for Maven 3.x as per MNG-1992.
Can we backport this to Maven 2.1.x and/or Maven 2.0.x?
This one seems a bit trickier - though it is clearly inconsistent I
could see how someone might have come to depend on it. Perhaps we can
detect when both are set, different, and it is used, and introduce a
warning that they may be using unsupported ordering in a future release?
Did these already have corresponding JIRAs for tracking?
Cheers,
Brett
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
