Hi Kit,

I've created a JIRA for this issue, here: https://jira.jboss.org/browse/JBOSGI-415

Could you please attach the bundles that are needed to reproduce to the JIRA?

Thanks!

David

According to the spec, a version range oes not allow leading/trailing whitespace. The trim belongs in the caller and the XVersion.parse(String) method should throw an IllegalArgumentException

http://github.com/jbosgi/jbosgi-resolver/commit/f62b62da97143aea786e8aa8186389d27286a6a1

The bug is probably in the metadata parser I assume

However, this bundle deploys fine with Equinox and Felix. I think we should be a little lenient and trim that string instead of throwing an exception. Interestingly the org.osgi.Version class does this trimming too and it's even part of the javadoc: see here.

In our code we also trim components of a version range if the interval syntax is used. It would be a little inconsistent to not allow this case (where " 1.6.0" - leading space) is consumed fine by org.osgi.Version.parseVersion() but throws an exception in ore XVersionRange.parse().

Who is the caller of this or more presicely where is that range data comming from? My assumption maybe incorrect, but here it is anyway ...

I assume that the range is obtained from OSGiMetaData if the proposed fix goes in like this it means that one client of OSGiMetaData fixes the whitespace issue all other clients of that data may still have this bug right now or even in the future. My proposal is that the whitespace issue is fixed where it occurs (i.e. in the parser or the metadata) and not on a case by case basis in a ramdom client.

It comes straight from the manifest, which contains the following Import-Package line.

{code}Import-Package: org.osgi.service.log;version=1.3, org.apache.felix.ipo
 jo.architecture;version= 1.6.0, org.apache.felix.ipojo;version= 1.6.0
 , org.osgi.framework;version=1.3, org.osgi.service.cm;version=1.2{code}

As you can see there are additional spaces in there.

I would be open to fixing it another place, but fixing it in the in the XVersionRange.parse() seemed like a nice and single place to me. Esp given that there is already trimming going on in the XVersionRange.parse() for ranges that use the interval syntax: "[1, 2]"

XVersionRange.parse() seemed like a nice and single place

I complain because the contrary seems to be true. Could you please check that we don't have an issue at a much lower level ( i.e. ParameterizedAttribute) It is possible that our meta data mode returns whitespace arround all sorts of attributes and even directives. If that is the case we would have a ton of trim issues in all sorts of places.

IMHO, attributes and directives should already been trimmed in OSGiMetaData