Maven
  1. Maven
  2. MNG-1943

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: