Hi Oleg, 2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>: > Working on Mercury I faced the necessity to use some standard definition of > a "version range", so I took OSGi definition: OSGi core specs 4.1, page 39 > in April-2007 PDF available on OSGi site - http://osgi.org. > > Some interesting ramifications for Maven users: > > 1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3: 1.2.3 > <= X. We are used to a soft version of that in Maven builds - version can be > replaced by a more applicable dependency. But spec states ANY version: i.e. > found in any scanned repository.
Isn't this essentially what we have now with Maven? A soft dependency of 1.2.3 can be replaced by any other version as determined by the conflict resolution mechanism (currently nearest-wins). If OSGi mandates that soft versions can only be resolved to versions greater or equal to the suggested version then this seems more robust than what we currently have. > 2). I strongly feel that failing any explicit ranges, containing snapshots > is a good thing. For instance, dependency declaration 1.2-SNAPSHOT is a > range by definition, so I'd rather fail anything like [1.2-SNAPSHOT,2.0) or > [1.0,1.2-SNAPSHOT) Are you referring to failing at release time here? I agree that a project containing dependencies with version ranges that contain snapshots should not be allowed to be released. > 3). Declaration [2.0, 2.1) should exclude 2.1-SNAPSHOT, but include > 2.1-alpha-1, etc Welcome to the debate :) I say that a version range should only resolve to a snapshot if it is included as an explicit boundary. See http://jira.codehaus.org/browse/MNG-3092 You may also be interested in the other issues on my hit list for being able to use version ranges in Maven: http://jira.codehaus.org/browse/MNG-2994 http://jira.codehaus.org/browse/MRELEASE-262 http://jira.codehaus.org/browse/MRELEASE-318 Regarding Michael's suggestion of using repositories to control whether ranges resolve to snapshots or not: the problem with this is that it's an all or nothing approach. For example, say I need to fix a bug in Project A 3.0 that depends on Project B 2.0, amongst many other dependencies. I take A 3.0 and determine that the bug is in B 2.0, so I want to update the dependency of B in A to 2.1-SNAPSHOT. Assuming that this range was initially declared as B[2.0,3.0), using the repository approach I would just enable snapshot repositories for the range to resolve to my new work-in-progress B 2.1-SNAPSHOT. This works, but it would also open the gates for all other ranged dependencies to resolve to snapshots too, which I certainly don't want. Whereas if ranges behaved as I've described, then we would just update B to [2.0,2.1-SNAPSHOT) during development and then reinstate [2.0,3.0) once the fixed B 2.1 has been released. > Please comment if this does not sound natural or breaks some > well-established usage patterns. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
