Maven 2 & 3

using ${version} for subproject dependencies doesn't work (maven uses 2.4.1 version instead)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Inheritance and Interpolation
  • Labels:
    None
  • Environment:
    win xp, maven 2.0.1, eclipse plugin 0.0.3, eclipse 3.1
  • Complexity:
    Intermediate
  • Number of attachments :
    3

Description

My project is a ear multiproject. It has 5 modules, that have internal dependencies. For example web module needs app and type modules.

I usually use following declaration for this kind of dependencies. Note that I'm using $

{version} in dependency. In result I'm requesting foo-type jar of the same version as current project.

<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>foo</groupId>
<artifactId>foo</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>foo-app</artifactId>

<dependencies>
<dependency>
<groupId>foo</groupId>
<artifactId>foo-type</artifactId>
<version>${version}

</version>
</dependency>
</dependencies>
</project>

This works from commandline, but doesn't work in eclipse plugin. I get following message:

"Unable to download the artifact from any repository foo:foo-type-2.4.1.jar"

Maven (or maven plugin) tries to download foo-type module in very strange version (instead 0.0.1-SNAPSHOT)!

I've attached simple multimodule project.

  2. Text File
    org.maven.ide.eclipse-MNGECLIPSE-20-patch.txt
    04/Nov/06 3:57 PM
    8 kB
    Daniel Schulz
  1. mngeclipse20-trigger.jpg
    13 kB
    06/Nov/06 1:41 AM

Issue Links

depends upon

Bug - A problem which impairs or prevents the functions of the product. MNG-2651 POM interpolator treats ${pom.something} like ${something} and prefers system properties

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. MNGECLIPSE-41 Pickup embedder component 2.0.2

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
duplicates

Bug - A problem which impairs or prevents the functions of the product. MNG-2339 ${project.*} are interpreted in the wrong place

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MECLIPSE-259 transitiv dependency version set to incorrect version 2.4.1

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNGECLIPSE-30 Maven plugin keeps looking for non-existent apacheds-*-2.4.1 dependency

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNGECLIPSE-145 dependencyManagement in parent poms broken in eclipse on linux

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-2796 Yet another snapshot/timestamp version resolution problem

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNGECLIPSE-30 Maven plugin keeps looking for non-existent apacheds-*-2.4.1 dependency

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Eugene Kuleshov added a comment -

Jason, this is happening with 2.0.2 embedder. The strange thing that execute install from the embedder is working fine, but readProjectWithDependencies() is pulling off version "2.4.1" out of nowhere.

Show
Eugene Kuleshov added a comment - Jason, this is happening with 2.0.2 embedder. The strange thing that execute install from the embedder is working fine, but readProjectWithDependencies() is pulling off version "2.4.1" out of nowhere.
Hide
Permalink
Eugene Kuleshov added a comment -

Same problem with embedder 2.0.3

Show
Eugene Kuleshov added a comment - Same problem with embedder 2.0.3
Hide
Permalink
Jozef Kotlár added a comment -

With version 0.0.7 (e.g. embedder 2.0.4) there seems to be used correct versions in provided sample project.

Show
Jozef Kotlár added a comment - With version 0.0.7 (e.g. embedder 2.0.4) there seems to be used correct versions in provided sample project.
Hide
Permalink
Eugene Kuleshov added a comment -

Veified against trunk version. Probably been working in earlier versions too.

Show
Eugene Kuleshov added a comment - Veified against trunk version. Probably been working in earlier versions too.
Hide
Permalink
Daniel Schulz added a comment -

quick explanation:

i found the reason for the "$

{pom.version} > 2.4.1" problem. there is a system property of name "version" set to "2.4.1" in your eclipse jvm (see [Eclipse]>Help->About Eclipse Platform->Configuration Details).

more detailed explanation:

Some eclipse plugin or component (no names please) set it. it does'nt matter if you set pom.version, project.version, env.version or a property of name version. if a system property of that name ist set, it beats them all, because the pom variable evaluation order is 1) system properties, 2) project properties and at last 3) pom properties via reflection (see org.apache.maven.project.interpolation.RegexBasedModelInterpolator for Details). Try it by calling "mvn -Dversion=2.4.1 install".

possible quick fix:

I fixed the problem by adding an overloaded RegexBasedModelInterpolator-Implementation to my copy of m2eclipse, that filters out the system property "version" and gets version from POM. (Patch file added).

possible not so quick fix:

The impl of RegexBasedModelInterpolator should be changed. By using ${pom.version}

everyone expects, that an evaluator reads out the version property of the POM. I'll look if there is already an issue for that.

BTW and in the future everyone should use $

{pom.version}

. Using $

{version}

is dangerous, because it uses a side effect of the RegexBasedModelInterpolator implementation.

Show
Daniel Schulz added a comment - quick explanation: i found the reason for the "$ {pom.version} > 2.4.1" problem. there is a system property of name "version" set to "2.4.1" in your eclipse jvm (see [Eclipse] >Help->About Eclipse Platform->Configuration Details). more detailed explanation: Some eclipse plugin or component (no names please) set it. it does'nt matter if you set pom.version, project.version, env.version or a property of name version. if a system property of that name ist set, it beats them all, because the pom variable evaluation order is 1) system properties, 2) project properties and at last 3) pom properties via reflection (see org.apache.maven.project.interpolation.RegexBasedModelInterpolator for Details). Try it by calling "mvn -Dversion=2.4.1 install". possible quick fix: I fixed the problem by adding an overloaded RegexBasedModelInterpolator-Implementation to my copy of m2eclipse, that filters out the system property "version" and gets version from POM. (Patch file added). possible not so quick fix: The impl of RegexBasedModelInterpolator should be changed. By using ${pom.version} everyone expects, that an evaluator reads out the version property of the POM. I'll look if there is already an issue for that. BTW and in the future everyone should use $ {pom.version} . Using $ {version} is dangerous, because it uses a side effect of the RegexBasedModelInterpolator implementation.
Hide
Permalink
Daniel Schulz added a comment -

again the quick explanation:

i found the reason for the "$

{pom.version}

is 2.4.1" problem. there is a system property of name "version" set to "2.4.1" in your eclipse jvm (see [Eclipse]>Help>About Eclipse Platform->Configuration Details).

Show
Daniel Schulz added a comment - again the quick explanation: i found the reason for the "$ {pom.version} is 2.4.1" problem. there is a system property of name "version" set to "2.4.1" in your eclipse jvm (see [Eclipse] >Help >About Eclipse Platform->Configuration Details).
Hide
Permalink
Daniel Schulz added a comment -

Patch with changed RegexBasedModelInterpolator impl.

Show
Daniel Schulz added a comment - Patch with changed RegexBasedModelInterpolator impl.
Hide
Permalink
Daniel Schulz added a comment -

problem trigger

Show
Daniel Schulz added a comment - problem trigger
Hide
Permalink
Michal Stochmialek added a comment -

Basing on Daniel's comments the issue should be reopened.

Show
Michal Stochmialek added a comment - Basing on Daniel's comments the issue should be reopened.
Hide
Permalink
Eugene Kuleshov added a comment -

Folks, please report it to the Maven Embedder component. This issue should be fixed in there and not worked around in the plugin.

Show
Eugene Kuleshov added a comment - Folks, please report it to the Maven Embedder component. This issue should be fixed in there and not worked around in the plugin.
Hide
Permalink
Nathan Pruett added a comment - - edited

This should be left as an open issue until it is fixed in Maven Embedder (MNG-2651) and the new version of Maven Embedder is included in the Eclipse plugin.

Show
Nathan Pruett added a comment - - edited This should be left as an open issue until it is fixed in Maven Embedder ( MNG-2651 ) and the new version of Maven Embedder is included in the Eclipse plugin.
Hide
Permalink
Kenney Westerhof added a comment -

I'm tempted to 'close - won't fix'.
$

{version}

is evaluated to either a system prop or a -Dversion=..., so this is expected.

However, $

{pom.version}

should be evaluated to the pom's <version> tag. But that's a different issue alltogether.

Show
Kenney Westerhof added a comment - I'm tempted to 'close - won't fix'. $ {version} is evaluated to either a system prop or a -Dversion=..., so this is expected. However, $ {pom.version} should be evaluated to the pom's <version> tag. But that's a different issue alltogether.

People

  • Assignee:
    Kenney Westerhof
    Reporter:
    Michal Stochmialek
Vote (7)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: