Maven 2 & 3

${project.version} evaluated to timestamped version if referring to SNAPSHOT

Details

  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

when projects specify dependencyManagement sections with a shorthand version notation using the current project version (using $

{project.version}

) the version resolved will be that of the POM in which the dependencyManagement section is specified. If this POM is a snapshot, these dependency specifications will get the timestamp/buildnumber of that POM, instead of the actual one used when the dependency it references gets deployed.

We should look at strategies for limiting or eliminating this practice, or else (somehow) pulling the real timestamp/buildnumber for that artifact from the reactor...in order to make these deps transitively resolvable for users.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. SUREFIRE-218 Unable to use 2.3-SNAPSHOT

  • Blocker - Blocks development and/or testing work, production could not run
  • 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. MNG-2647 Version not inherited for SNAPSHOT version

  • 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. 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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

is this a duplicate of MNG-2339?

Show
Brett Porter added a comment - is this a duplicate of MNG-2339 ?
Hide
Permalink
Brian Fox added a comment -

doht. I got burned on this one. Isn't it possible when a pom is deployed to resolve the property to the actual version? Then it would be safe to use the $

{project.version}

in dependencies.

Show
Brian Fox added a comment - doht. I got burned on this one. Isn't it possible when a pom is deployed to resolve the property to the actual version? Then it would be safe to use the $ {project.version} in dependencies.
Hide
Permalink
Olivier Lamy added a comment -

Due to MNG-2651 ?
This issue will be fix with 2.0.5 ?

Show
Olivier Lamy added a comment - Due to MNG-2651 ? This issue will be fix with 2.0.5 ?
Hide
Permalink
Kenney Westerhof added a comment -

This issue deals with the fact that whenever $

{project.version}

or $

{pom.version}

is evaluated to a POM <version> tag (be it parent,
or project, present in a dependency or dependencyManagement or anywhere else in the POM),
and that version is a SNAPSHOT version, then the timestamped version is used, instead of the literal string.

This causes problems with multimodule builds that share versions but aren't always deployed as a whole.
Even if they are deployed as a whole, this could cause problems since the timestamps might not be the same for all artifacts.

Show
Kenney Westerhof added a comment - This issue deals with the fact that whenever $ {project.version} or $ {pom.version} is evaluated to a POM <version> tag (be it parent, or project, present in a dependency or dependencyManagement or anywhere else in the POM), and that version is a SNAPSHOT version, then the timestamped version is used, instead of the literal string. This causes problems with multimodule builds that share versions but aren't always deployed as a whole. Even if they are deployed as a whole, this could cause problems since the timestamps might not be the same for all artifacts.
Hide
Permalink
Jason Dillon added a comment -

Copying my comments from MNG-2796

IMO, maven should never change the value of $

{pom.version} ... if a pom says:
<project>
    ...
    <version>1.2-SNAPSHOT</version>
    ...
</project>


Then ${pom.version}

should always resolve to 1.2-SNAPSHOT. If you need to know what the timestamp-build version is then I suggest adding $

{pom.effectiveVersion} which can change dynamically.

Also, I can hear this coming... "why don't you use <dependencyManagement>...". This feature of Maven is great for managing external dependencies, but for internal module management it becomes unmanageable quickly.

For Geronimo, we have ~200+ modules and to enumerate each one of those in a <dependencyManagement> is unruly, and tends to become unmaintained quickly. Its much easier to use <version>${pom.version}</version> in poms when defining dependencies sibling modules.

But, as noted by David, this won't work when dealing with snapshots as when deploying a snapshot, the module being deployed will have its ${pom.version} changed magically to the timestamp-build version which is going to produce invalid dependencies, since the dependencies using <version>${pom.version}</version> now have invalid versions (using the deployed modules timestamp-build version not the timestamp-build version of the dependency.

I really think the best way to handle this is to never change the value of ${pom.version} and introduce a ${pom.effectiveVersion}

which will dynamically change.

  • * *

I'd really, really really really, really like to see this get fixed sooner rather than later. I think a pom.version that doesn't change and a pom.effectiveVersion that does change (to reflect the SNAPSHOT's timestamp-buildnumber) would be a fine solution... hint hint

Show
Jason Dillon added a comment - Copying my comments from MNG-2796 IMO, maven should never change the value of $ {pom.version} ... if a pom says: <project> ... <version>1.2-SNAPSHOT</version> ... </project> Then ${pom.version} should always resolve to 1.2-SNAPSHOT . If you need to know what the timestamp-build version is then I suggest adding $ {pom.effectiveVersion} which can change dynamically. Also, I can hear this coming... "why don't you use <dependencyManagement>...". This feature of Maven is great for managing external dependencies, but for internal module management it becomes unmanageable quickly. For Geronimo, we have ~200+ modules and to enumerate each one of those in a <dependencyManagement> is unruly, and tends to become unmaintained quickly. Its much easier to use <version>${pom.version}</version> in poms when defining dependencies sibling modules. But, as noted by David, this won't work when dealing with snapshots as when deploying a snapshot, the module being deployed will have its ${pom.version} changed magically to the timestamp-build version which is going to produce invalid dependencies, since the dependencies using <version>${pom.version}</version> now have invalid versions (using the deployed modules timestamp-build version not the timestamp-build version of the dependency. I really think the best way to handle this is to never change the value of ${pom.version} and introduce a ${pom.effectiveVersion} which will dynamically change. * * I'd really, really really really, really like to see this get fixed sooner rather than later. I think a pom.version that doesn't change and a pom.effectiveVersion that does change (to reflect the SNAPSHOT's timestamp-buildnumber) would be a fine solution... hint hint
Hide
Permalink
Bo Conroy added a comment -

Are there any known workarounds for this? We have a pretty large project that is running into this issue often. We are using maven-2.0.9.

Show
Bo Conroy added a comment - Are there any known workarounds for this? We have a pretty large project that is running into this issue often. We are using maven-2.0.9.
Hide
Permalink
Brian Fox added a comment -

I'm pretty sure this is already fixed even in 2.x.

Show
Brian Fox added a comment - I'm pretty sure this is already fixed even in 2.x.
Hide
Permalink
Benjamin Bentmann added a comment -

This is already fixed in 2.0.5. The reason this might have shown up with later versions as well is that the actual issue is caused by badly deployed POMs, which would make newer Maven versions fail as well.

Show
Benjamin Bentmann added a comment - This is already fixed in 2.0.5. The reason this might have shown up with later versions as well is that the actual issue is caused by badly deployed POMs, which would make newer Maven versions fail as well.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    John Casey
Vote (12)
Watch (13)

Dates

  • Created:
    Updated:
    Resolved: