Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 3.0-alpha-3
-
Component/s: Inheritance and Interpolation
-
Labels:None
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
-
MSITE-585
site-deploy: empty deploy protocol when properties are used
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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 
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.
Perhaps the problem I describe in MNG-1775 (Comment James Olsen [15/Aug/06 06:37 AM]) is a symptom of this issue?
this is an integration test ready to add to core-integration-tests when this issue is completed.
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?
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.
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-71whether 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.