Currently I'm trying to implement OSGI Version Ranges (for a different topic, but I like the way they define version ranges). However I'm having a hard time to find the specific Definition of a Version Range in OSGI.
Unfortunately, the OSGI API does contain a Version class but not a VersionRange class. It seems like all OSGI Containers come up with their own interpretation of the (somewhat unfindable) Version Range definition.
Therefore I have several questions:
versionRange=1.4.0
, would this map to Version >= 1.4.0? versionRange=[1.0.0,0]
: I'd say yes (version 1.0.0 up to any version), Eclipse implementation accepts it as a version but does not handle it correctly.
versionRange=[1.0.0,0)
? Version ranges are precisely defined in section 3.2.6 of the OSGi Core Specification. You're correct that there is no VersionRange
class in the current API, though there will be in the next specification release.
OSGi framework implementations do not come up with their own interpretation of ranges; if you find a case where a specific framework interprets a range differently from section 3.2.6 of the Core Spec then please raise a bug against that framework.
To address your specific questions:
Yes, version=1.4.0
on an Import-Package
(or bundle-version=1.4.0
on a Require-Bundle
) does map informally to "version >= 1.4.0".
I believe that both of these version ranges are valid, BUT they will never match any version. E.g. first example will match only version x
where x >= 1.0.0
and x<=0
. There is no value of x
that can satisfy both of these requirements. So it sounds like Eclipse is behaving correctly... it should successfully parse the range string but never return any results.
As already mentioned, the "source for truth" is section 3.2.6 of the OSGi Core Specification.... page 29 if you are reading the R4.3 version of the document.
So, to answer your concrete questions in order:
- If I used versionRange=1.4.0, would this map to Version >= 1.4.0?
Yes. This is exactly the way spec says it should be interpreted (see below).
- Is this a valid version range: versionRange=[1.0.0,0]
Yes, it is a valid range, but it will not evaluate to what you seem to be expecting. It effectively evaluates to an empty set of versions, so no version will match this expression.
- Would this be a valid versionRange aswell: versionRange=[1.0.0,0)?
Same as above -- it is a valid version range, but it will evaluate to an empty set.
- Where is the actual source of truth for all those questions? I seem to be unable to find it
The specs are available on OSGi Alliance's home page from: http://www.osgi.org/Release4/Download (for R4 specs)
Below is an excerpt from the OSGi R4 core specification that covers the version ranges:
Version Ranges
A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation.
The syntax of a version range is:
version-range ::= interval | atleast
interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' )
atleast ::= version
floor ::= version
ceiling ::= version
If a version range is specified as a single version, it must be interpreted as the range
[version,
∞)
. The default for a non-specified version range is 0, which maps to[0.0.0,
∞)
.Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example:
Import-Package: com.acme.foo;version="[1.23, 2)",
com.acme.bar;version="[4.0, 5.0)"
In the following table, for each specified range in the left-hand column, a version x is considered to be a member of the range if the predicate in the right-hand column is true.
[1.2.3, 4.5.6) | 1.2.3 <= x < 4.5.6
[1.2.3, 4.5.6] | 1.2.3 <= x <= 4.5.6
(1.2.3, 4.5.6) | 1.2.3 < x < 4.5.6
(1.2.3, 4.5.6] | 1.2.3 < x <= 4.5.6
1.2.3 | 1.2.3 <= x
1) versionRange=1.4.0 is equivalent to [1.4.0, infinity)
2) I'd say it isn't valid, since the floor should be lower than the ceiling.
3) The next OSGi spec will define a VersionRange class, I believe.
See RFC 175 in http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2011-09.pdf. It defines an update to the version definition and also introduces a VersionRange class.
Version ranges can be empty such as your example in the second bullet. An empty version range includes no versions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With