You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2009/01/11 23:06:29 UTC
YAPII
Hi,
there are two subtle differences between Maven 2.x and 3.x regarding POM
interpolation I would like to discuss.
a) Ordering of Interpolation Sources
According to section 6.1 of the POM spec for Maven 3.x, the precedence
of interpolation sources is:
1. Maven Props
2. System Props
3. POM Props
4. Environment Props
In particular, system properties dominate POM values, i.e. "mvn package
-Dproject.version=0.1" will override the project version as given in the
POM. This is different compared to Maven 2.x where model values can't be
overriden by system properties.
As far as I understand 3.x, the reasoning for the above ordering is that
"POM Props" include both reflective data from the model and the values
from the <properties> section (which, I agree, should be dominated by
system props).
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. Maven Props (e.g. basedir)
2. Model Values
3. System Props
4. <properties> section
5. Environment Props
b) Resolution of Expressions
Consider this POM snippet:
<properties>
<project.prop>A</project.prop>
<prop>B</prop>
<foo>C</foo>
</properties>
<name>${project.prop} - ${prop} - ${foo}</name>
If there was a "Maven certified developer", a nice question for his exam
could be "What is the effective value of the <name> element?".
Well, in Maven 2.x it's "B - B - C". In Maven 3.x, it's "A - B - C".
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?
Benjamin
P.S.: For those that sill wonder what YAPII means: "Yet Another POM
Interpolation Issue". Sorry, but I was in strange mood.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: YAPII
Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:
> Sorry for the delayed reply.
Better late than never :-)
> I would say not 2.0.x, but I think it makes sense for 2.1.x.
Sounds good.
> I believe we could drop the "stripped" syntax already and handle it with errors
> when used.
Not sure whether we should really produce an error/exception. I would
just have the expression pass through like any other undefined property,
e.g. null or the literal expression, whatever Maven currently does.
> 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?
The warning is a nice idea to ease migration but about what Maven
versions are we talking here exactly? E.g. fix 2.1.x to be consistent
and output the warning in 2.0.x or leave the entire 2.x line as is and
output the warning?
> Did these already have corresponding JIRAs for tracking?
The latter one is MNG-1992, I haven't come across a JIRA for the first
issue with the non-prefixed lookup so far (it's quite an edge case and
not easily noticed unless a plugin looks at the effective model, say by
inspecting other plugin configs).
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: YAPII
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: YAPII
Posted by Benjamin Bentmann <be...@udo.edu>.
Benjamin Bentmann schrieb:
> According to section 6.1 of the POM spec for Maven 3.x, the precedence
> of interpolation sources is:
>
> 1. Maven Props
> 2. System Props
> 3. POM Props
> 4. Environment Props
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?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org