[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT

["Jason Dillon (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104077 ] 

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:

{code}
<project>
    ...
    <version>1.2-SNAPSHOT</version>
    ...
</project>
{code}

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*



> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
> ----------------------------------------------------------------------------
>
>                 Key: MNG-2486
>                 URL: http://jira.codehaus.org/browse/MNG-2486
>             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 reactor...in 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: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira