Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0.4
-
Fix Version/s: Issues to be reviewed for 3.x
-
Component/s: Inheritance and Interpolation
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
In the Clover plugin I'm modifying the finalName with:
getProject().getBuild().setFinalName( getProject().getArtifactId() + "-" + getProject().getVersion() + "-clover" );
This works fine and all subsequent plugins using the MavenProject object do work fine. However if the user uses, say, the AntRun plugin and uses the ${project.build.fineName} expression in his POM it'll return the original value and not the one modified by the Clover plugin. For example if the user is using the AntRun plugin combined with xdoclet Ant tasks to generate files, they won't be put in the correct target directories when used with the Clover plugin and the build will fail...
See http://jira.codehaus.org/browse/MCLOVER-59 for an issue filed against the Clover plugin on this.
I think we need a way for reevaluating interpolated expressions when the model is changed.
Thanks
-Vincent
In DefaultMavenProjectBuilder.processProjectLogic:
// TODO: this is a hack to ensure
MNG-2124can be satisfied without triggeringMNG-1927//
MNG-1927relies on the false assumption that ${project.build.*} evaluates to null, which occurs before//
MNG-2124is fixed. The null value would leave it uninterpolated, to be handled after path translation.// Until these steps are correctly sequenced, we guarantee these fields remain uninterpolated.
context.put( "build.directory", null );
context.put( "build.outputDirectory", null );
context.put( "build.testOutputDirectory", null );
context.put( "build.sourceDirectory", null );
context.put( "build.testSourceDirectory", null );
My guess is that this is the same bug, and that adding build.finalName to that list would fix the problem (albeit in a rather unclean fashion).
MNG-2186,MNG-1927, andMNG-2124have a little more information, but the manifestation/reporting of the issue is rather different in each case. Unfortunately I don't have access to a machine for testing right now.Also of interest, Brett's comment on the checkin of that fix:
MNG-2186correct the regression ofMNG-1927from the solution ofMNG-2124The interpolator was only working based on an incorrect assumption for a limited set of expressions. This assumption is
guaranteed by the solution in the interim, until it can be properly reconsidered. The proper solution would be to not
cache an interpolated model, and to apply path translation and then interpolation after retrieving the cached model. However,
this will require some other related changes and should be planned for 2.1.
The caching of the interpolated model appears to be the problem here as well (as evidenced through the use of help:effective-pom to see the cached values).
Cheers,
Chris
MNG-2124can be satisfied without triggeringMNG-1927//MNG-1927relies on the false assumption that ${project.build.*} evaluates to null, which occurs before //MNG-2124is fixed. The null value would leave it uninterpolated, to be handled after path translation. // Until these steps are correctly sequenced, we guarantee these fields remain uninterpolated. context.put( "build.directory", null ); context.put( "build.outputDirectory", null ); context.put( "build.testOutputDirectory", null ); context.put( "build.sourceDirectory", null ); context.put( "build.testSourceDirectory", null ); My guess is that this is the same bug, and that adding build.finalName to that list would fix the problem (albeit in a rather unclean fashion).MNG-2186,MNG-1927, andMNG-2124have a little more information, but the manifestation/reporting of the issue is rather different in each case. Unfortunately I don't have access to a machine for testing right now. Also of interest, Brett's comment on the checkin of that fix:MNG-2186correct the regression ofMNG-1927from the solution ofMNG-2124The interpolator was only working based on an incorrect assumption for a limited set of expressions. This assumption is guaranteed by the solution in the interim, until it can be properly reconsidered. The proper solution would be to not cache an interpolated model, and to apply path translation and then interpolation after retrieving the cached model. However, this will require some other related changes and should be planned for 2.1. The caching of the interpolated model appears to be the problem here as well (as evidenced through the use of help:effective-pom to see the cached values). Cheers, Chris