Bugzilla – Full Text Bug Listing
| Summary: | Update all package import version ranges of H2 driver to < 2.0.0 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Victor Roldan Betancort <vroldanbet> | ||||||
| Component: | cdo.core | Assignee: | Victor Roldan Betancort <vroldanbet> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | gnagy | ||||||
| Version: | 4.0 | Flags: | stepper:
review+
|
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Victor Roldan Betancort
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 |