Community
Participate
Working Groups
RFC 138 defines a new FrameworkFactory service which allows for the creation of child frameworks and also provides a means of linking two frameworks which can be used to share packages and services from a source framework to a target framework.
Targeting M4. I have been prototyping this feature for a while now. I plan to release an initial implementation soon.
I was close to releasing an implementation of 138 but we decided to significantly change the API for creating child frameworks and how to share packages and services with them. We should have the API locked down this week and hopefully have an implementation before M4 is done.
This is slipping to M5. I have an initial implementation done, but it needs to be cleaned up. The API is likely to change. I do not want to release a half-baked implementation with an API that is likely to change into M4. I plan to release the initial implementation into M5 before the end of the year.
OSGi is currently calling these LinkBundles. I really want to change the name the CompositeBundles. The concept seems to fit well for me. We have a bundle composed of 1..n bundles that happen to be running in a child framework. The composite can import/export resources to/from the composite bundle.
The name of the API has been changed to CompositeBundle and CompositeBundleFactory. We have also introduced another bundle type (SurrogateBundle) which represents the composite inside the child framework. I have released a rough implementation of the new API into the RFC138_work branch. I will continue to polish the code in this branch and hope to release the code to HEAD before the first I-Build in January.
I released the latest code from the branch into HEAD.
Marking as fixed for M5. Additional changes may come to the API in M6. Also note that the composite bundles specification will be made a "proposed" specification for the OSGi R4.2 release. This means from an Eclipse perspective the API for composite bundles is provisional (internal) and not real API.