Community
Participate
Working Groups
Currently package imports of the H2 driver are specified as [1.1.0, 1.2.0). Set it to [1.1.0, 2.0.0).
Created attachment 188893 [details] patch v1 changed version ranges
I've changed the range to [1.0.0,2.0.0)
Created attachment 189012 [details] Patch v2 - ready to be committed
Committed to TRUNK, Revision 7085
We also stumbled upon this issue on our project, thanks for fixing it! One thing I'd like to note is that the official H2 release ships with an OSGI manifest, however the package exports are not versioned. Because the eclipse-packaged h2 manifest has versioned package exports, these seem to take precedence over the upstream h2 jar, if both are installed. Would you consider changing the dependency declaration to require bundle, so the upstream jar can be used as-is?
(In reply to comment #5) > We also stumbled upon this issue on our project, thanks for fixing it! > > One thing I'd like to note is that the official H2 release ships with an OSGI > manifest, however the package exports are not versioned. Because the > eclipse-packaged h2 manifest has versioned package exports, these seem to take > precedence over the upstream h2 jar, if both are installed. Would you consider > changing the dependency declaration to require bundle, so the upstream jar can > be used as-is? To clarify, the eclipse-packaged h2 jar takes precedence over upstream even if the former has a lower version.
(In reply to comment #5) > [...] Would you consider changing the dependency declaration to require > bundle, so the upstream jar can be used as-is? The root cause of your problem is that the bundle manifest originally provided by the H2 maintainers is sloppy at best. We certainly don't want to decrease the quality of our own manifests to compensate that. Please submit an RFE to the H2 maintainers, similar to what I did for MongoDB: http://jira.mongodb.org/browse/JAVA-272 Generally we don't want to introduce implementation dependencies to third party components, i.e. Require-Bundle, as that would prevent users from plugging in their own H2 bundles. In addition we're bound to what the Orbit project offers.
(In reply to comment #7) > (In reply to comment #5) > > [...] Would you consider changing the dependency declaration to require > > bundle, so the upstream jar can be used as-is? > > The root cause of your problem is that the bundle manifest originally provided > by the H2 maintainers is sloppy at best. We certainly don't want to decrease > the quality of our own manifests to compensate that. Please submit an RFE to > the H2 maintainers, similar to what I did for MongoDB: > > http://jira.mongodb.org/browse/JAVA-272 > > Generally we don't want to introduce implementation dependencies to third party > components, i.e. Require-Bundle, as that would prevent users from plugging in > their own H2 bundles. > > In addition we're bound to what the Orbit project offers. Issue submitted upstream: http://code.google.com/p/h2database/issues/detail?id=294
(In reply to comment #7) > The root cause of your problem is that the bundle manifest originally provided > by the H2 maintainers is sloppy at best. I apologize for this obvious exaggeration! The H2 maintainers are very responsive to this issue and seem very interested in making the situation for OSGi users better ;-) I recognize that issues with bundle manifests not always result from sloppyness but often from the complexity of the OSGi specification itself. To be a little more constructive, here is a link to a brief article that discusses some of the common misconceptions: http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
Available in R20110608-1407
