Maven 2 & 3

[regression] Version x.y.z.SNAPSHOT resolution/deployment not handled correctly

Details

  • Type: Bug Bug
  • Status: Reopened Reopened
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 3.0
  • Fix Version/s: None
  • Component/s: Deployment
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

When using a version that ends with ".SNAPSHOT" instead of the usual "-SNAPSHOT", Maven 3.0 changes the project version to the timestamped version. So "5.2.0.SNAPSHOT" becomes something like "5.2.0.20101109.215833-1". A Nexus snapshot repository will reject this deployment because the version in the directory name does not end with "SNAPSHOT".

I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not work in Maven 3.0. The build returns an HTTP 400 error when deploying to Nexus.

Error from Nexus log

2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is forbidden by Maven Repository 
policy. Because snapshots is a SNAPSHOT repository
2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got exception during processing 
request "PUT http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom": Storing of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is forbidden by Maven Repository 
policy. Because snapshots is a SNAPSHOT repository

Issue Links

relates to

Task - A task that needs to be done. MNG-4957 Emit validation warning when project version uses irregular SNAPSHOT version string

  • Trivial - Cosmetic problem like misspelt words or misaligned text.
  • 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
Benjamin Bentmann added a comment -

This is caused by an inconsistency in snapshot detection. Maven [2.0, 3.0] consider "5.2.0-20101110.030222-361" a snapshot version but not "5.2.0.20101110.030222-361" whereas the corresponding base forms "5.2.0-SNAPSHOT" and "5.2.0.SNAPSHOT" are both considered snapshot versions. I.e. if one tried to resolve the timestamped snapshot 5.2.0.20101110.030222-361 as a dependency, it would fail as well.

Show
Benjamin Bentmann added a comment - This is caused by an inconsistency in snapshot detection. Maven [2.0, 3.0] consider "5.2.0-20101110.030222-361" a snapshot version but not "5.2.0.20101110.030222-361" whereas the corresponding base forms "5.2.0-SNAPSHOT" and "5.2.0.SNAPSHOT" are both considered snapshot versions. I.e. if one tried to resolve the timestamped snapshot 5.2.0.20101110.030222-361 as a dependency, it would fail as well.
Hide
Permalink
Brian Fox added a comment -

I think we should stick with the x.y.z-SNAPSHOT form for both expanded and non-expanded forms. Widening that pattern in Maven is just bound to cause additional problems in all the ecosystem tools that need to interpret snapshot v release

Show
Brian Fox added a comment - I think we should stick with the x.y.z-SNAPSHOT form for both expanded and non-expanded forms. Widening that pattern in Maven is just bound to cause additional problems in all the ecosystem tools that need to interpret snapshot v release
Hide
Permalink
Jason van Zyl added a comment -

Why exactly do you need x.y.z.SNAPSHOT instead of x.y.z-SNAPSHOT? If they are trying have OSGi versioning then we should probably have something that means something in OSGi which would be x.y.z.qualifier. We want to move toward OSGi and this could be the first step. But I think you just took advantage of something we were doing wrong. We can probably help Mark Proctor fix the Drools build.

Show
Jason van Zyl added a comment - Why exactly do you need x.y.z.SNAPSHOT instead of x.y.z-SNAPSHOT? If they are trying have OSGi versioning then we should probably have something that means something in OSGi which would be x.y.z.qualifier. We want to move toward OSGi and this could be the first step. But I think you just took advantage of something we were doing wrong. We can probably help Mark Proctor fix the Drools build.
Hide
Permalink
Geoffrey De Smet added a comment -

Drools recently dumped the bad snapshot way (.SNAPSHOT) for the good way (-SNAPSHOT) because maven 3 couldn't deal with it and it's better to do it right.

Show
Geoffrey De Smet added a comment - Drools recently dumped the bad snapshot way (.SNAPSHOT) for the good way (-SNAPSHOT) because maven 3 couldn't deal with it and it's better to do it right.
Hide
Permalink
Benjamin Bentmann added a comment -

As discussed, going forward *-SNAPSHOT is the only snapshot version format we want to support. A corresponding warning for irregular snapshot versions has been added as per MNG-4957.

Show
Benjamin Bentmann added a comment - As discussed, going forward *-SNAPSHOT is the only snapshot version format we want to support. A corresponding warning for irregular snapshot versions has been added as per MNG-4957 .
Hide
Permalink
John Casey added a comment - - edited

Still, it's interesting that Maven 3.0.4 isn't treating this as either a release OR a snapshot:

[DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://localhost/aprox/api/1.0/group/cs-repo
Downloading: http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml
[...]
Downloading: http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom
[...]
[WARNING] The POM for com.redhat.services.rest.user:user-rest-client-java:jar:1.0.0.20110720.215608-33 is missing, no dependency information available

You'll notice that it's grabbing the maven-metadata.xml from the 1.0.0.SNAPSHOT version dir, then using that to formulate a new URL (just as it would for a snapshot). The problem is, it's formatting the URL incorrectly. So, it appears we have a half-baked snapshot implementation where .SNAPSHOT is concerned.

Whether or not we choose to support .SNAPSHOT, this is broken.

Show
John Casey added a comment - - edited Still, it's interesting that Maven 3.0.4 isn't treating this as either a release OR a snapshot: [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://localhost/aprox/api/1.0/group/cs-repo Downloading: http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.SNAPSHOT/maven-metadata.xml [...] Downloading: http://localhost/aprox/api/1.0/group/cs-repo/com/redhat/services/rest/user/user-rest-client-java/1.0.0.20110720.215608-33/user-rest-client-java-1.0.0.20110720.215608-33.pom [...] [WARNING] The POM for com.redhat.services.rest.user:user-rest-client-java:jar:1.0.0.20110720.215608-33 is missing, no dependency information available You'll notice that it's grabbing the maven-metadata.xml from the 1.0.0.SNAPSHOT version dir, then using that to formulate a new URL (just as it would for a snapshot). The problem is, it's formatting the URL incorrectly. So, it appears we have a half-baked snapshot implementation where .SNAPSHOT is concerned. Whether or not we choose to support .SNAPSHOT, this is broken.
Hide
Permalink
John Casey added a comment -

It's still broken, even if we suppose that .SNAPSHOT isn't supported. If that's true, then x.y.z.SNAPSHOT should be treated as a release version (not interpreted at all)...and it's not. See my comment just above this one.

Show
John Casey added a comment - It's still broken, even if we suppose that .SNAPSHOT isn't supported. If that's true, then x.y.z.SNAPSHOT should be treated as a release version (not interpreted at all)...and it's not. See my comment just above this one.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Paul Gier
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: