Maven 2 & 3

${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

This issue is duplicated by:
MNG-3009 Maven 2.0.5+ fails to resolve ${project.version} on deployment Blocker Closed
MNG-2653 using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead) Major Closed
MNG-2651 POM interpolator treats ${pom.something} like ${something} and prefers system properties Major Closed
MNG-2782 Version property in dependencies is not expanded correctly Major Closed
MNG-2745 Do not allow System properties to be interpolated in the POM Major Closed
This issue is related to:
SUREFIRE-113 surefire-providers-2.0.pom contains strange dependencies which generate error Major Closed
This issue is depended upon by:
ARCHETYPE-78 Dependencies listed as version ${project.version} in maven-archetype prevent the use of archetypes Critical Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Kenney Westerhof added a comment -

this is not fixed.

Show
Kenney Westerhof added a comment - this is not fixed.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
Brian Fox 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
Brian Fox 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
Permalink
Brian Fox 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
Brian Fox 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
Permalink
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
Permalink
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

Vote (15)
Watch (14)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.