[ 
https://jira.codehaus.org/browse/MNG-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343689#comment-343689
 ] 

Robert Thornton commented on MNG-5611:
--------------------------------------

In experimenting with a potential fix that would make the runtime interpolation 
consistent with the effective pom, there are two aspects of how interpolation 
is being done that makes a fix for this issue difficult.

First, the model is not interpolated until after all parent models have been 
read (in {{DefaultModelBuilder.build}}) even though properties in the child 
model override properties in the parent.

Applying the following line of code within the {{DefaultModelBuilder.build}} 
method just before the call to {{readParent}} allows the parent to be resolved 
from the remote repository using the properties defined in the project.

{code:java}
tmpModel = interpolateModel(tmpModel, request, problems); // MNG-5611
currentData = readParent( tmpModel, currentData.getSource(), request, problems 
);
{code}

However, this exposes the second problem with how model interpolation is 
implemented. Two test case fail due to the parent model's properties overriding 
child properties as discovered from the following two integration tests:
{code}
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithoutProfiles
org.apache.maven.project.PomConstructiontest.testInheritedPropertiesInterpolatedWithValuesFromChildWithActiveProfiles
{code}

I believe the reason these tests fail is that after the properties of the child 
project are interpolated (due to the potential fix in the code snippet above), 
it somehow causes the parent properties to override the child properties in the 
effective pom because all properties are interpolated at once instead of 
"on-demand". But since the child properties in this use case will override any 
properties in the parent model, it seems pointless to wait for the parent model 
to be loaded before these properties can be interpolated, especially when their 
interpolation is necessary to resolving the parent.

I'm not sure if the current implementation for properties resolution will allow 
for a resolution to this issue. But the problem, as I see it is that the 
effective pom, which *does* resolve these properties as expected does not 
accurately describe the model being used at the time the repositories are being 
created by the implementation.

> Project properties are interpolated too late to be used in several parts of 
> the pom
> -----------------------------------------------------------------------------------
>
>                 Key: MNG-5611
>                 URL: https://jira.codehaus.org/browse/MNG-5611
>             Project: Maven 2 & 3
>          Issue Type: Bug
>    Affects Versions: 3.2.1
>            Reporter: Robert Thornton
>
> I need projects that declare my pom as their parent to be able to define 
> project properties to customize essential components of their build, such as 
> repositories, pluginRepositories, and distributionManagement.
> For example:
> {code:xml}
> <parent>
>     <groupId>org.apache.maven.its.mng5611</groupId>
>     <artifactId>parent</artifactId>
>     <version>0.1</version>
> </parent>
> <properties>
>     <!--
>     Using properties allows repository definitions to be customized, 
> enabled/disabled, and tuned by child projects
>     which is useful when you have several repositories that can be configured 
> with a few simple properties.
>     -->
>     <repo.url>http://repo.mysite.com/nexus/content</repo.url>
>     <repo.releases.enabled>true</repo.releases.enabled>
>     <repo.snapshots.enabled>false</repo.snapshots.enabled>
>     <repo.update>daily</repo.update>
> </properties>
> <repositories>
>     <!-- Parent pom needs to be read from this repository -->
>     <repository>
>         <id>my-repo</id>
>         <name>My Repository</name>
>         <url>${repo.url}/groups/main-repo</url>
>         <releases>
>             <enabled>${repo.releases.enabled}</enabled>
>             <updatePolicy>${repo.update}</updatePolicy>
>         </releases>
>         <snapshots>
>             <enabled>${repo.snapshots.enabled}</enabled>
>             <updatePolicy>${repo.update}</updatePolicy>
>         </snapshots>
>     </repository>
> </repositories>
> <pluginRepositories>
>     <pluginRepository>
>         <id>my-plugin-repo</id>
>         <name>My Plugin Repository</name>
>         <url>${repo.url}/groups/plugin-repo</url>
>         <releases>
>             <enabled>${repo.releases.enabled}</enabled>
>             <updatePolicy>${repo.update}</updatePolicy>
>         </releases>
>         <snapshots>
>             <enabled>${repo.snapshots.enabled}</enabled>
>             <updatePolicy>${repo.update}</updatePolicy>
>         </snapshots>
>     </pluginRepository>
> </pluginRepositories>
> {code}
> The bug is that the effective pom correctly shows these properties as being 
> interpolated for the above repositories, however the Aether RemoteRepository 
> objects for the above definitions are created before the pom's properties are 
> interpolated. This results in unexpected behavior that can only be understood 
> by attaching a debugger to the Maven build process. The above example fails, 
> for example, if the above pom's parent is in the repository whose properties 
> haven't been interpolated yet.
> The way I believe the properties interpolation process should work is that 
> any time a project property is requested (as in the above examples), it 
> should be interpolated based on the currently available project properties 
> even if the entire project hierarchy has not yet been loaded.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

Reply via email to