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 <bri...@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.conno...@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
>> br...@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
