Maven 2.x Release Plugin

Replace dependency version for <version>RELEASE</version> dependency.

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0-beta-8
  • Fix Version/s: None
  • Component/s: prepare
  • Labels:
    None
  • Number of attachments :
    0

Description

I 'm using RELEASE version for some dependencies in my current project.

Imagine a simple scenario where i have project A who depends on project B...,

A's pom.xml states:

...
<dependency>
<artifactId>b</artifactId>
<groupId>ar.com.b</groupId>
<version>RELEASE</version>
</dependency>
...

When running "mvn compile" to A, there maven knows which is B's last released version so that it can compile against certain specific code at that time, imagine it is 1.2.0.

So why when I run "mvn release:prepare" A's tagged (released, svn cp) pom.xml doesn't replace <version>RELEASE</version> with <version>1.2.0</version> ?

Why do i think it should?

  • So that A's released version will always work the same as that day I performed A's release
  • So that A's released version won't get hurted by possible non-backward-compatible changes on future B's releases

I 've read at the Maven Definitive Guide e-book that use of <version>RELEASE</version> is not encouraged, but i seemed helpful for me until this point where I find this quite dissapointing.

Please feel free to share thoughts may be I got confused with this but i think this is a problem that worth to be solved.

Issue Links

is related to

New Feature - A new feature of the product, which has yet to be developed. MRELEASE-479 Option to handle plugins missing explicit version number

  • 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
Thomas Sauzedde added a comment - - edited

+1 for this proposal.

I'll also be happy to see such a behavior and not only for <dependency> but also for the <parent> block !

In a sub-module, this will allow to use something like :
<parent>
<groupId>com.acme</groupId>
<artifactId>parent</artifactId>
<version>RELEASE</version>
</parent>

to stick to the newest <dependencyManagement> block defined in the "parent" and when cutting a sub-module release, to have the proper, unique "parent" version used by the release plugin at that time !

Show
Thomas Sauzedde added a comment - - edited +1 for this proposal. I'll also be happy to see such a behavior and not only for <dependency> but also for the <parent> block ! In a sub-module, this will allow to use something like : <parent> <groupId>com.acme</groupId> <artifactId>parent</artifactId> <version>RELEASE</version> </parent> to stick to the newest <dependencyManagement> block defined in the "parent" and when cutting a sub-module release, to have the proper, unique "parent" version used by the release plugin at that time !
Hide
Permalink
Nicolas Adrian Barrera added a comment -

Thomas,

I 've been working on the plugin source code for a while before going on holidays for the last 2 weeks and I could made some changes on the source to replace the parent version from RELEASE to the last release resolved version.

I wasn't sure if those changes were alright so I didn't post them as I 've never collaborate on an open source project yet I don't know how should I share my changes...

Perhaps I post them later as a diff between the base working copy with only those changes included and the svn tag I 've download.

comments are welcome.

cheers

Show
Nicolas Adrian Barrera added a comment - Thomas, I 've been working on the plugin source code for a while before going on holidays for the last 2 weeks and I could made some changes on the source to replace the parent version from RELEASE to the last release resolved version. I wasn't sure if those changes were alright so I didn't post them as I 've never collaborate on an open source project yet I don't know how should I share my changes... Perhaps I post them later as a diff between the base working copy with only those changes included and the svn tag I 've download. comments are welcome. cheers
Hide
Permalink
Thomas Sauzedde added a comment -

You can ask / propose your patch here of course but posting (or asking) on the dev. mailing list could be another way ... (dev at maven.apache.org)

It's great that someone is really working on the topic

Regards

Show
Thomas Sauzedde added a comment - You can ask / propose your patch here of course but posting (or asking) on the dev. mailing list could be another way ... (dev at maven.apache.org) It's great that someone is really working on the topic Regards
Hide
Permalink
Martin Eigenbrodt added a comment -

I would be very interested in the patch. Replacing dynamic with static revisions is a feature I'm used to from ivy and I'm really missing in maven.

Show
Martin Eigenbrodt added a comment - I would be very interested in the patch. Replacing dynamic with static revisions is a feature I'm used to from ivy and I'm really missing in maven.
Hide
Permalink
Danilo Ghirardelli added a comment -

This wuold be very interesting, expecially for those internal projects and parent poms. It would be way better that disabling entirely the feature as in maven 3.
IMHO, typical use case for this feature is the "shared"/"interfaces"/"singleSignOn" (or similar) project that is imported in many company projects, that is seldom updated (and only to add something or for bugfix).

Show
Danilo Ghirardelli added a comment - This wuold be very interesting, expecially for those internal projects and parent poms. It would be way better that disabling entirely the feature as in maven 3. IMHO, typical use case for this feature is the "shared"/"interfaces"/"singleSignOn" (or similar) project that is imported in many company projects, that is seldom updated (and only to add something or for bugfix).

People

  • Assignee:
    Unassigned
    Reporter:
    Nicolas Adrian Barrera
Vote (5)
Watch (7)

Dates

  • Created:
    Updated: