Maven 2 & 3

MavenProject::getParent() returns a MavenProject that is NOT interpolated

Details

  • Complexity:
    Expert
  • Number of attachments :
    1

Description

Plugin developers repeatedly use $

{project}

.getParent().someMethod() yet getParent() returns a project that has not been interpolated. This obviously needs to be fixed but may I also suggest that all plugin acceptance testing is revisted to ensure that the tests use POMs that are littered with property expressions and not literals.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MSITE-585 site-deploy: empty deploy protocol when properties are used

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

I'm not sure we should interpolate it by default. It's a rare case that the interpolated model is needed. I will see for MSITE-71 whether I can use the interpolation component from the plugin.

As for integration tests - we have those for interpolation, what we really need is parent interpolation.

Show
Brett Porter added a comment - I'm not sure we should interpolate it by default. It's a rare case that the interpolated model is needed. I will see for MSITE-71 whether I can use the interpolation component from the plugin. As for integration tests - we have those for interpolation, what we really need is parent interpolation.
Hide
Permalink
John Allen added a comment -

Brett,

re 'a rare case', obviously my familiarity with these internal APIs and there usage is greatly limited so I will defer to your expertese but in general I would have thought that if someone is using an accessor to retreive a value they will want the cooked version of that 'property' and not an internal/meta representation of it, after all what use is $

{foo.bar}

to the developer who has called getUrl()?

I'll keep a keen eye out for your MSITE-71 code as I have a number of plugins that i've had to make reactor dependent in order to gain access to properly interpolated parent model data.

re 'integration tests' - yep, thats exactly what i meant

Show
John Allen added a comment - Brett, re 'a rare case', obviously my familiarity with these internal APIs and there usage is greatly limited so I will defer to your expertese but in general I would have thought that if someone is using an accessor to retreive a value they will want the cooked version of that 'property' and not an internal/meta representation of it, after all what use is $ {foo.bar} to the developer who has called getUrl()? I'll keep a keen eye out for your MSITE-71 code as I have a number of plugins that i've had to make reactor dependent in order to gain access to properly interpolated parent model data. re 'integration tests' - yep, thats exactly what i meant
Hide
Permalink
Brett Porter added a comment -

I agree anyone calling getParent wants the cooked version. It's a rare case that someone wants the parent as opposed to the already merged values in their own project.

Show
Brett Porter added a comment - I agree anyone calling getParent wants the cooked version. It's a rare case that someone wants the parent as opposed to the already merged values in their own project.
Hide
Permalink
James Olsen added a comment -

Perhaps the problem I describe in MNG-1775 (Comment James Olsen [15/Aug/06 06:37 AM]) is a symptom of this issue?

Show
James Olsen added a comment - Perhaps the problem I describe in MNG-1775 (Comment James Olsen [15/Aug/06 06:37 AM] ) is a symptom of this issue?
Hide
Permalink
John Casey added a comment -

this is an integration test ready to add to core-integration-tests when this issue is completed.

Show
John Casey added a comment - this is an integration test ready to add to core-integration-tests when this issue is completed.
Hide
Permalink
Nate Good added a comment -

I have just experienced this issue in a more critical use case. Here are the details. Please let me know if you need more information.

$

{buildVersion} is a property defined in a profile in settings.xml and is used in all poms.

<parent>
  <artifactId>bar</artifactId>
  <groupId>foo.bar</groupId>
  <version>${buildVersion}

</version>
</parent>

It seems that the problem presents itself when a project depends on an artifact that has a parent with a non-literal value; and the parent pom is not located on the filesystem.

Example:

pom.xml - This is the master pom that all others inherit from
Project A
  pom.xml - Inherits from master pom
  A.x
    pom.xml - inherits from ProjectA/pom.xml

Project B
  pom.xml - depends on A.x

if you run maven on ProjectB and A.x is located in a remote repository it will fail because $

{buildVersion} in A.x/pom.xml will not be interpolated before it is used to lookup the pom.

Here is the resulting stack trace (from version 2.0.9):

Caused by: org.apache.maven.project.ProjectBuildingException:
Cannot find parent: foo.bar:xyz-pom for project: foo.bar:prompting-client:jar:${buildVersion}

for project foo.bar:zyx-client:jar:$

{buildVersion}

at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253)
at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:106)

Is this scheduled to be fixed in the next maven release?

Show
Nate Good added a comment - I have just experienced this issue in a more critical use case. Here are the details. Please let me know if you need more information. $ {buildVersion} is a property defined in a profile in settings.xml and is used in all poms. <parent>   <artifactId>bar</artifactId>   <groupId>foo.bar</groupId>   <version>${buildVersion} </version> </parent> It seems that the problem presents itself when a project depends on an artifact that has a parent with a non-literal value; and the parent pom is not located on the filesystem. Example: pom.xml - This is the master pom that all others inherit from Project A   pom.xml - Inherits from master pom   A.x     pom.xml - inherits from ProjectA/pom.xml Project B   pom.xml - depends on A.x if you run maven on ProjectB and A.x is located in a remote repository it will fail because $ {buildVersion} in A.x/pom.xml will not be interpolated before it is used to lookup the pom. Here is the resulting stack trace (from version 2.0.9): Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: foo.bar:xyz-pom for project: foo.bar:prompting-client:jar:${buildVersion} for project foo.bar:zyx-client:jar:$ {buildVersion} at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:253) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:106) Is this scheduled to be fixed in the next maven release?
Hide
Permalink
Shane Isbell added a comment -

3.0 does interpolation of the parent. I wasn't able to get the attached IT to run, as it is relying on old, non-existent snapshots.

Show
Shane Isbell added a comment - 3.0 does interpolation of the parent. I wasn't able to get the attached IT to run, as it is relying on old, non-existent snapshots.

People

  • Assignee:
    Shane Isbell
    Reporter:
    John Allen
Vote (2)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: