Maven 2 & 3

Expressions in POMs are not modified when the Maven Project is updated

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    1

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

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chris Tucker added a comment -

In DefaultMavenProjectBuilder.processProjectLogic:
// TODO: this is a hack to ensure MNG-2124 can be satisfied without triggering MNG-1927
// MNG-1927 relies on the false assumption that $

{project.build.*}

evaluates to null, which occurs before
// MNG-2124 is 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, and MNG-2124 have 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-2186 correct the regression of MNG-1927 from the solution of MNG-2124
The 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

Show
Chris Tucker added a comment - In DefaultMavenProjectBuilder.processProjectLogic: // TODO: this is a hack to ensure MNG-2124 can be satisfied without triggering MNG-1927 // MNG-1927 relies on the false assumption that $ {project.build.*} evaluates to null, which occurs before // MNG-2124 is 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 , and MNG-2124 have 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-2186 correct the regression of MNG-1927 from the solution of MNG-2124 The 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
Hide
Permalink
Chris Tucker added a comment -

Addition of build.finalName to list did fix the problem. Patch attached.

Show
Chris Tucker added a comment - Addition of build.finalName to list did fix the problem. Patch attached.
Hide
Permalink
Daniel Gredler added a comment -

Any news on this? We've had to apply this patch locally to fix our build environment...

Show
Daniel Gredler added a comment - Any news on this? We've had to apply this patch locally to fix our build environment...
Hide
Permalink
John Casey added a comment -

The supplied patch only addresses the build.finalName expression, not any number of other values in MavenProject (or Model, which is what we're really talking about).

IMO, we need to address this more generally, rather than continue adding to the exceptions list Brett put together to satisfy one funky little case we had that depended on broken functionality.

Show
John Casey added a comment - The supplied patch only addresses the build.finalName expression, not any number of other values in MavenProject (or Model, which is what we're really talking about). IMO, we need to address this more generally, rather than continue adding to the exceptions list Brett put together to satisfy one funky little case we had that depended on broken functionality.
Hide
Permalink
Jussi Vesala added a comment -

Hello!

Do we have any news on this? Fixing this would make my life a lot easier.

Show
Jussi Vesala added a comment - Hello! Do we have any news on this? Fixing this would make my life a lot easier.

People

  • Assignee:
    Unassigned
    Reporter:
    Vincent Massol
Vote (8)
Watch (6)

Dates

  • Created:
    Updated: