Community
Participate
Working Groups
At a Core 4.3 spec review meeting, OSGi split the BundleWirings type in two. BundleWirings will be for non-fragment bundles and the new FragmentWirings type will be for fragments bundles. Equinox needs to support this new type.
Created attachment 186947 [details] Patch to support new FragmentWirings type The patch adds the new FragmentWirings type and updates BundleFragment to adapt to it instead of BundleWirings.
Comment on attachment 186947 [details] Patch to support new FragmentWirings type Patch is obsolete. FragmentWirings has been removed.
At the next Core 4.3 spec review, the FragmentWirings type was demonstrated to be a bad idea. The BundleWirings type (and FragmentWirings) type did not take into account that a bundle can change from a host to a fragment or vice versa upon update. It is the revisions of bundle for which a list is needed. The BundleRevisions type is added and methods are added to BundleRevision to access the BundleWiring objects associated with the BundleRevision. The changes for this were more complex that I could quickly provide a patch. So I leave the code changes to Tom.
Created attachment 187534 [details] patch This patch includes all the latest changes to the org.osgi.framework for R4.3. This patch also included the fix for bug334532 for ease of testing against the latest OSGi CT. Since this contains the latest org.osgi.framework changes it also includes the fix for bug334574.
I am changing the title to reflect the general changes OSGi has made to the wiring API: - Capability is renamed to BundleCapability - BundleWirings is gone. There is now a BundleRevisions interface which can be used to find old removal pending bundles. - WiredCapability is gone. A concept of BundleWire is added to represent wires between BundleRequirement objects and BundleCapability objects. - BundleWiring interface has had a number of methods removed which used the WiredCapability type. Methods dealing with attached fragment revisions has also been removed. Fragments can now be discovered through the use of BundleWire objects using the osgi.wiring.host namespace.
This change also affects the following: Package org.osgi.framework.hooks.resolver Changes are in the org.osgi.framework.hooks.resolver package to the ResolverHook interface to the filterMatches method: Old M5 method: void filterMatches(BundleRevision requirer, Collection<Capability> candidates) New M6 method: void filterMatches(BundleRequirement requirement, Collection<BundleCapability> candidates); In M5 this method took a parameter of type BundleRevision which represented the bundle revision with a requirement. In M6 the method will take a BundleRequirement object instead to represent the actual requirement. The BundleReqiurement object allows you to get access to the requirer BundleRevision. Package org.eclipse.osgi.service.resolver - BundleWiring are obtained directly from the BundleRevision interface which BundleDescription implements. This eliminated the need for the BundleDescription.getBundleWiring() method. - A number of other changes were made to accommodate the change from Capability to BundleCapability type as well as the introduction of the BundleWire concept.
Comment on attachment 187534 [details] patch This patch is obsolete given the other changes to the wiring package.
I have been working on the changes to the wiring package in a branch OSGI_R4_3_Wiring of org.eclipse.osgi. I have merged the changes back into HEAD.
