Mark Hobson wrote:
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.
Mark - this is the same if one excludes repositories and lives within
pre-existing version set: like Maven having only local repo and OSGi
having one OBR file.
If we add a variable - repositories that constantly change, then we
start wondering what to do and OSGi joins this discussion as soon as
they add this feature.
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.
I agree, and it's also too demanding an approach; it requires users to
know a lot of details. In my opinion - build system should be more
transparent and less intrusive.
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.
Why not using 2.1-SNAPSHOT directly? Including it into the range is
messier solution if you ask me. In both cases you have to change the
pom, so there is not distinct advantage in either .
BTW - thanks for the references!
Oleg
