|
Addition of build.finalName to list did fix the problem. Patch attached.
Any news on this? We've had to apply this patch locally to fix our build environment...
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. Hello!
Do we have any news on this? Fixing this would make my life a lot easier. |
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Expressions in POMs are not modified when the Maven Project is updated
// 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