Maven
  1. Maven
  2. MNG-2339

${project.*} are interpreted in the wrong place

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.4
    • Fix Version/s: 2.0.9
    • Component/s: General
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      If a plugin use $

      {project.version}, this parameter is interpreted with the version of the current project and not the plugin version. I think we have the same pb with dependencies and other ${project.*}

      For a plugin in version 2.0 used in a project in version 1.0-SNAPSHOT, ${project.version}

      used in the plugin will be interpreted as 1.0-SNAPSHOT instead of 2.0

        Issue Links

          Activity

          Hide
          Carlos Sanchez added a comment -

          This bug showed up in surefire-providers pom

          Show
          Carlos Sanchez added a comment - This bug showed up in surefire-providers pom
          Hide
          Brett Porter added a comment -

          Carlos - are you sure? The surefire plugin works for most people even with that published, and the plugin itself does not depend on any providers or the providers pom itself.

          Show
          Brett Porter added a comment - Carlos - are you sure? The surefire plugin works for most people even with that published, and the plugin itself does not depend on any providers or the providers pom itself.
          Hide
          Carlos Sanchez added a comment -

          In surefire-providers

          <dependency>
          <groupId>$

          {project.groupId}

          </groupId>
          <artifactId>surefire-api</artifactId>
          <version>2.1-SNAPSHOT</version>
          <!-- commenting this due to MNG-2339
          <version>$

          {project.version}</version>
          -->
          </dependency>

          If you put back <version>${project.version}

          </version>, deploy and clean your repo org/apache/maven/surefire dir, you'll get the problem

          Show
          Carlos Sanchez added a comment - In surefire-providers <dependency> <groupId>$ {project.groupId} </groupId> <artifactId>surefire-api</artifactId> <version>2.1-SNAPSHOT</version> <!-- commenting this due to MNG-2339 <version>$ {project.version}</version> --> </dependency> If you put back <version>${project.version} </version>, deploy and clean your repo org/apache/maven/surefire dir, you'll get the problem
          Hide
          Wayne Fay added a comment -

          We've seen this on the Users list specifically affecting Spring jars (context)... Wondering if anyone is working on this?

          Show
          Wayne Fay added a comment - We've seen this on the Users list specifically affecting Spring jars (context)... Wondering if anyone is working on this?
          Hide
          Jason van Zyl added a comment -

          The POM is not interpolated on deploy anymore so this problem won't happen anymore. The POM will be deployed with the POM intact and it will be read back in correctly.

          Show
          Jason van Zyl added a comment - The POM is not interpolated on deploy anymore so this problem won't happen anymore. The POM will be deployed with the POM intact and it will be read back in correctly.
          Hide
          Kenney Westerhof added a comment -

          this is not fixed.

          Show
          Kenney Westerhof added a comment - this is not fixed.
          Hide
          Kenney Westerhof added a comment -

          This issue deals with $

          {project.version}, or ${version}, or ${xxx.version} for that matter, all being treated like ${version}.
          commandline arguments like -Dversion=foo will have effect on the dependencies or wherever one of the expressions above is used.

          ${project.version}

          and $

          {pom.version}

          should ALWAYS resolve to a <version> tag in the pom.

          RegexBasedModelInterpolator strips off the first part (project.) and then checks the context for the value. This is wrong.

          Issue MNG-2486 is different - that one deals with the fact that SNAPSHOT version expressions, which are correctly interpolated from the pom and not from external properties,
          are evaluated to the timestamped version instead of the string present in the model.

          Show
          Kenney Westerhof added a comment - This issue deals with $ {project.version}, or ${version}, or ${xxx.version} for that matter, all being treated like ${version}. commandline arguments like -Dversion=foo will have effect on the dependencies or wherever one of the expressions above is used. ${project.version} and $ {pom.version} should ALWAYS resolve to a <version> tag in the pom. RegexBasedModelInterpolator strips off the first part (project.) and then checks the context for the value. This is wrong. Issue MNG-2486 is different - that one deals with the fact that SNAPSHOT version expressions, which are correctly interpolated from the pom and not from external properties, are evaluated to the timestamped version instead of the string present in the model.
          Hide
          Kenney Westerhof added a comment -

          Comitted fix in r549786 on trunk (2.1).
          It produces lots of warnings - i'm not sure we want exactly that behaviour in 2.0.

          See http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation

          Show
          Kenney Westerhof added a comment - Comitted fix in r549786 on trunk (2.1). It produces lots of warnings - i'm not sure we want exactly that behaviour in 2.0. See http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
          Hide
          Stefan Behnel added a comment -

          Maybe not "exactly that behaviour", but leaving this bug in 2.0.x renders that release mostly useless. So any fix will be appreciated.

          Show
          Stefan Behnel added a comment - Maybe not "exactly that behaviour", but leaving this bug in 2.0.x renders that release mostly useless. So any fix will be appreciated.
          Hide
          brianfox brianfox added a comment -

          Any one of the watchers/ voters care to make an IT test for this? http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test

          Show
          brianfox brianfox added a comment - Any one of the watchers/ voters care to make an IT test for this? http://docs.codehaus.org/display/MAVEN/Creating+a+Maven+Integration+Test
          Hide
          brianfox brianfox added a comment -

          bumping to 2.0.9. If we get IT tests for these before 2.0.8 is final, we can take a look

          Show
          brianfox brianfox added a comment - bumping to 2.0.9. If we get IT tests for these before 2.0.8 is final, we can take a look
          Hide
          Grzegorz Kossakowski added a comment -

          Guys, the situation with this issue is really, really annoying.

          The issue is more than one year old, affects so many people that most of them (including me) sees it as the most ugliest unresolved bug in Maven. I don't know why you require any IT even if there are many projects (Apache Cocoon, Jetty plug-in, Spring to name a few) that exhibit behaviour described in this issue.

          At Apache Cocoon, we have many poms polluted just because of this issue and our users who being worried about whole Maven thing are hit by it at the nearly beginning, see: http://article.gmane.org/gmane.text.xml.cocoon.user/63302 for latest example. It's not perfect first expierience, don't you think?
          Demanding any additional action for such embarrassing bug is just a PITA, IMHO.

          Sorry for a little rant but I think it's the time to say: enough is enough.

          Devoted Maven user,
          Grzegorz

          Show
          Grzegorz Kossakowski added a comment - Guys, the situation with this issue is really, really annoying. The issue is more than one year old, affects so many people that most of them (including me) sees it as the most ugliest unresolved bug in Maven. I don't know why you require any IT even if there are many projects (Apache Cocoon, Jetty plug-in, Spring to name a few) that exhibit behaviour described in this issue. At Apache Cocoon, we have many poms polluted just because of this issue and our users who being worried about whole Maven thing are hit by it at the nearly beginning, see: http://article.gmane.org/gmane.text.xml.cocoon.user/63302 for latest example. It's not perfect first expierience, don't you think? Demanding any additional action for such embarrassing bug is just a PITA, IMHO. Sorry for a little rant but I think it's the time to say: enough is enough. Devoted Maven user, Grzegorz
          Hide
          Brett Porter added a comment -

          this has regressed the path alignment of $

          {project.build.directory}

          . I'll add a test for it.

          Show
          Brett Porter added a comment - this has regressed the path alignment of $ {project.build.directory} . I'll add a test for it.

            People

            • Assignee:
              Brett Porter
              Reporter:
              Emmanuel Venisse
            • Votes:
              15 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: