maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Dillon (JIRA)" <>
Subject [jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
Date Mon, 06 Aug 2007 09:29:13 GMT


Jason Dillon commented on MNG-2486:

Copying my comments from MNG-2796

IMO, maven should *never* change the value of ${pom.version} ... if a pom says:


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

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*

> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
> ----------------------------------------------------------------------------
>                 Key: MNG-2486
>                 URL:
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Dependencies, Inheritance and Interpolation, POM
>    Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1-alpha-1
>            Reporter: John Casey
>            Priority: Critical
>             Fix For: 2.0.8, 2.1-alpha-1
> 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 order to make
these deps transitively resolvable for users.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message