You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brian E. Fox" <br...@reply.infinity.nu> on 2009/01/22 20:39:54 UTC
RE: What is the preferred API call to effect ${foo} substitution in an arbitrary string.
Inheritence happens first and then interpolation. So if you put it in
the parent, it's essentially the same as putting it in the child and it
will have the value defined in the child.
Now if you are simply trying to validate the property, take a look at
the requireProperty enforcer rule. You can validate the property's
existence and optionally regex the value to make sure it's set properly:
http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Thursday, January 22, 2009 1:58 PM
To: Maven Developers List
Subject: Re: What is the preferred API call to effect ${foo}
substitution in an arbitrary string.
Well would it help if I pointed out that these are snippets of the
pom.xml file (or it's parents)... specifically, they're the <version>
tags from <plugin> definitions!
(It's the versions-maven-plugin) and I'm trying to ensure that
<version>${plugin.version.install}</version> evaluates correctly... of
course somebody might have forced the plugin version they are using to
be the same as either their project version or their parent's project
version...
Now a second question is this....
if I have a pluginManagement section in the parent pom that specifies
a version of the plugin using a property *that is defined with
different values in both the parent and child projects*, and the
parent and child are not in the same reactor... what version should
the child project be using?
Is it:
A. The version defined by the property in the parent pom
B. The version defined by the property in the child pom.
My feeling is that it should be A, but it's probably B!
I'm leaving it up to the enforcer to warn people of these issues, I
just whan to know what version is effectively defined in the child
pom.
-Stephen
2009/1/22 Brett Porter <br...@apache.org>:
> You're probably better getting the PluginParameterExpressionEvaluator
> component and using that (it's not the same as the interpolator in the
POM
> unfortunately, but probably what you are looking for and more
accessible).
>
> On 22/01/2009, at 6:55 AM, Stephen Connolly wrote:
>
>> I'm working on a mojo that needs to filter property and maven model
>> property-equivalents (i.e. ${project.parent.groupId}).
>>
>> What is the preferred way to get these values?
>>
>> My current theory is that I should use
>>
>>
>>
http://maven.apache.org/ref/current/maven-project/xref/org/apache/maven/
project/interpolation/RegexBasedModelInterpolator.html
>>
>> But I'm somewhat unsure... and given that that refers to a Model, and
not
>> an
>> arbitrary string....
>>
>> -Stephen
>
> --
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What is the preferred API call to effect ${foo} substitution in
an arbitrary string.
Posted by Stephen Connolly <st...@gmail.com>.
Actually, I'm trying to catch the following situation:
https://svn.codehaus.org/mojo/trunk/mojo/versions-maven-plugin/src/it/it-103
Another situation I'm trying to catch is in it-104, which is briefly this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>localhost</groupId>
<artifactId>it-104</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
If I run with Maven 2.0.9, as I currently have the code defined, I see
the version from the super-pom, or rather I don't see that the version
is inherited from the super pom... but now that I think about it, as
the version is not defined, versions-maven-plugin should not tell me
about new versions anyway!.... Now why did I think I have a bug!
-Stephen
2009/1/22 Brian E. Fox <br...@reply.infinity.nu>:
> Inheritence happens first and then interpolation. So if you put it in
> the parent, it's essentially the same as putting it in the child and it
> will have the value defined in the child.
>
> Now if you are simply trying to validate the property, take a look at
> the requireProperty enforcer rule. You can validate the property's
> existence and optionally regex the value to make sure it's set properly:
>
>
> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Thursday, January 22, 2009 1:58 PM
> To: Maven Developers List
> Subject: Re: What is the preferred API call to effect ${foo}
> substitution in an arbitrary string.
>
> Well would it help if I pointed out that these are snippets of the
> pom.xml file (or it's parents)... specifically, they're the <version>
> tags from <plugin> definitions!
>
> (It's the versions-maven-plugin) and I'm trying to ensure that
> <version>${plugin.version.install}</version> evaluates correctly... of
> course somebody might have forced the plugin version they are using to
> be the same as either their project version or their parent's project
> version...
>
> Now a second question is this....
>
> if I have a pluginManagement section in the parent pom that specifies
> a version of the plugin using a property *that is defined with
> different values in both the parent and child projects*, and the
> parent and child are not in the same reactor... what version should
> the child project be using?
>
> Is it:
>
> A. The version defined by the property in the parent pom
> B. The version defined by the property in the child pom.
>
> My feeling is that it should be A, but it's probably B!
>
> I'm leaving it up to the enforcer to warn people of these issues, I
> just whan to know what version is effectively defined in the child
> pom.
>
> -Stephen
>
> 2009/1/22 Brett Porter <br...@apache.org>:
>> You're probably better getting the PluginParameterExpressionEvaluator
>> component and using that (it's not the same as the interpolator in the
> POM
>> unfortunately, but probably what you are looking for and more
> accessible).
>>
>> On 22/01/2009, at 6:55 AM, Stephen Connolly wrote:
>>
>>> I'm working on a mojo that needs to filter property and maven model
>>> property-equivalents (i.e. ${project.parent.groupId}).
>>>
>>> What is the preferred way to get these values?
>>>
>>> My current theory is that I should use
>>>
>>>
>>>
> http://maven.apache.org/ref/current/maven-project/xref/org/apache/maven/
> project/interpolation/RegexBasedModelInterpolator.html
>>>
>>> But I'm somewhat unsure... and given that that refers to a Model, and
> not
>>> an
>>> arbitrary string....
>>>
>>> -Stephen
>>
>> --
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org