[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=204600#action_204600 ] Brian Fox commented on MNG-2486: I'm pretty sure this is already fixed even in 2.x. > ${project.version} evaluated to timestamped version if referring to SNAPSHOT > > > Key: MNG-2486 > URL: http://jira.codehaus.org/browse/MNG-2486 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Inheritance and Interpolation, POM >Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 3.0-alpha-1 >Reporter: John Casey >Priority: Critical > Fix For: 3.0-alpha-7 > > > 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
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145497#action_145497 ] Bo Conroy commented on MNG-2486: 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. > ${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, 3.0-alpha-1 >Reporter: John Casey >Priority: Critical > Fix For: 3.0 > > > 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
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[ 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} ... 1.2-SNAPSHOT ... {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 ...". 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 is unruly, and tends to become unmaintained quickly. Its much easier to use ${pom.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 ${pom.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
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99676 ] Kenney Westerhof commented on MNG-2486: --- This issue deals with the fact that whenever ${project.version} or ${pom.version} is evaluated to a POM 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. > ${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