OSGi R5 aspect generates invalid version ranges

[JFingerle]

A bundle has the following header:

Import-Package: org.slf4j;version="[1.6.0,2.0.0)"

The OBR R5 index generated by Package Drone looks like this:

<requirement namespace="osgi.wiring.package">
<directive name="filter" value="(&(osgi.wiring.package=org.slf4j)(&(version>=1.6.0)(version<2.0.0)))"/>
</requirement>

Even though this expression is correct ("A version equal or greater than 1.6.0 and less 2.0.0") it does not match the OSGi R5 specification. It should look like this:

<requirement namespace="osgi.wiring.package">
<directive name="filter" value="(&(osgi.wiring.package=org.slf4j)(&(version>=1.6.0)(!(version>=2.0.0))))"/>
</requirement>

This expression ("A version equal or greater than 1.6.0 and not equal or greater than 2.0.0) is valid. For a sample have a look at page 570 of the OSGi Enterprise 5.0.0 specification. If you look at the method "toFilterString(String attributeName)" of the class "org.osgi.framework.VersionRange" (v5.0.0) you will also see that it throws an IllegalArgumentException for the attribute "<".

        for (char ch : attributeName.toCharArray()) {
            if ((ch == '=') || (ch == '>') || (ch == '<') || (ch == '~') || (ch == '(') || (ch == ')')) {
                throw new IllegalArgumentException("invalid attributeName \"" + attributeName + "\"");
            }
        }

This issue can be fixed quite easily. Although in my opinion Package Drone should better use "bindex" created by Neil Bartlett to generate the R5 index. The implemenation of bindex works very well and handles at lot more than the current implementation of Package Drone (e.g. Blueprint dependencies). The tool "bindex" has been merged with bnd this year. The code can be found here on github. I linked to the command line classes because they are a good example of how to use the bindex API.

[ctron]

I don't see how this violates the OSGi specification. The operator is not part of the attribute name and therefor should never trigger this code fragment. Putting in '>=' into this code fragment would fail as well.

[ctron]

My initial thought was to use bindex instead of doing something custom. However it turned out that bindex brought in a deep tree of dependencies which I don't want to pull in just for this functionality. Maybe it would be a good idea of modularize bindex to be usable as a library, then this would be a better match maybe. On the other hand I already stumbled over some oddities with P2, so having a custom implementation has it advantages as well ;-)

[JFingerle]

The operator is not part of the attribute name and therefor should never trigger this code fragment. Putting in '>=' into this code fragment would fail as well. This is true, the referenced method (toFilterString) has nothing to do with the value of the directive.

Nevertheless a R5 OBR provided by Package Drone can not be used in bndtools because of this issue. If one resolves against the OBR bndtools will show the following exeception:

Unable to resolve de.my.bundle version=1.1.0: missing requirement Parsing failed on (version<2.0.0) Expected an = after .

I currently can not prove to you that the expression used by Package Drone ("version<2.0.0") is incorrect by pointing at a section in the OSGi specification. Still I can find tons of samples searching google using the expression "!(version>=3.0.0)". I can't find any samples using the expression "version<2.0.0". I know this does not prove anything, but it high likely that the expression "version<2.0.0" is invalid.

[ctron]

So this seems more like a bug in bndtools then?!

Currently the versionRange method (in Filters.java) is only used by the R5 stuff. So I guess it is safe to just swap that logic. Although this blows up the node tree a bit it shouldn't do any harm.

[JFingerle]

I fixed this with commit aee968a721c4550c504eb1ebb97708d8c5a83221. I can now successfully resolve with Bndtools against the OBR R5 provided by Package Drone. The commit was automatically added to my pull request #127.

[junkerm]

I stumbled over this issue as well. In fact the filter syntax defined in the osgi core specfication [1], section 3.2.7, only allows <= and >= operators and not < or >.

[1] https://osgi.org/download/r6/osgi.core-6.0.0.pdf

[ctron]

@junkerm thanks for providing this!