Maven
  1. Maven
  2. MNG-2640

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.4
    • Fix Version/s: None
    • Labels:
      None
    • 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

        Hide
        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
        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
        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
        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
        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.
        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
        Hide
        Jason van Zyl added a comment -

        Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

        Show
        Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          People

          • Assignee:
            Unassigned
            Reporter:
            Vincent Massol
          • Votes:
            8 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: