You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ringo De Smet (JIRA)" <ji...@codehaus.org> on 2008/10/16 11:24:20 UTC

[jira] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions

    [ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150967#action_150967 ] 

Ringo De Smet commented on MNG-3092:
------------------------------------

Our project contains 200+ Maven2 modules. Currently, we have our CI server build SNAPSHOT versions of all modules, with the dependencies 

First of all, I would have expected version ranges to discard SNAPSHOTS. I didn't know about this bug until today, so I guess we must have been lucky that our CI server only uses a repository that contains released versions.

Assuming this bug wouldn't exist, this is the setup I'm aiming for: all the dependencies between the modules are defined as version ranges. We let our CI server build a complete release from all the modules using the Maven2 release plugin. In parallel, we have all the modules also built for the latest committed code (SNAPSHOT), but still using the released version of the dependencies. We define the version range for all dependencies in every project as a property in the POM. A developer that needs to integrate changes in a few modules wants to override the version range to pick up their local snapshot, or a remote one if available (work from colleagues for example). A developer can do this by defining an active profile and redefining the version properties for the modules they want to change. Such a scenario is independent of the contents of local and remote repositories. Even the remote repositories may contain snapshot artifacts.

Now what is the impact of this bug: with snapshots being picked up "by mistake", we have no control over the setup of all the developer machines! The first developer could have local snapshots of A, B and C, while another developer has snapshots B, C and D. If both want to build E on their local machine, the first could report failure, while the second one could report success. A see a lot of time getting lost trying to track down such scenarios. Don't forget that only a small subset of the developers have the knowledge of Maven2 and the whole project setup. All the others just install Maven2 and execute the build. They are hired to develop code, not to fiddle with Maven2. :-)

So please, fix this bug!

> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
>                 Key: MNG-3092
>                 URL: http://jira.codehaus.org/browse/MNG-3092
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Dependencies
>            Reporter: Mark Hobson
>            Assignee: Mark Hobson
>             Fix For: 2.0.11
>
>         Attachments: MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary."
> -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries.  Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.

-- 
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