Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 345790 - Delete composite bundle API and implementation
Summary: Delete composite bundle API and implementation
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.7   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: Luna M1   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2011-05-13 16:43 EDT by Thomas Watson CLA
Modified: 2013-05-06 09:56 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2011-05-13 16:43:16 EDT 
In the Equinox 3.5 release an implementation of an OSGi provisional API was included for composite bundles.  This API includes all classes from the org.osgi.service.framework package.  This provisional OSGi API has never been considered API by Equinox and as such has always been marked as x-internal.

The OSGi Alliance has decided to reject this provisional API.  It will never become a part of the official OSGi specification.  Any users of the org.osgi.service.framework composite bundle API must migrate to using framework hooks to provide additional isolation within a single OSGi framework.  See the sub-packages of org.osgi.framework.hooks for ways to control visibility/isolation for resolution, bundles and services.  Equinox plans to remove the org.osgi.service.framework API and composite bundle implementation in the Summer of 2012 (after the 3.8 release).

Equinox also has a region digraph implementation that allows for the definition and configuration of regions that can be used to isolate bundles.  The region digraph is built on top of the OSGi framework hooks.
Comment 1 John Arthorne CLA 2012-06-25 11:40:52 EDT 
We can now delete this.
Comment 2 Thomas Watson CLA 2012-06-25 11:55:07 EDT 
I plan to do this with the work I am doing to refactor the framework in preparation for Java 8 modules.  The complication of composites in the core framework will make prototyping an Java 8 module interop very hard.  It is unclear if this (Java 9 work) will be done in Kepler or not since the schedule for Java 8 is unclear.

I will mark for Kepler anyways since we should consider doing the removal regardless of Java 8.
Comment 3 Thomas Watson CLA 2012-08-01 11:02:14 EDT 
Seeing that M1 has crept up on me I am not going to push this in until M2.  I am thinking of not doing this at all for Kepler since it is looking like Kepler is shaping up to be more of a maintenance release from the framework perspective.
Comment 4 Thomas Watson CLA 2012-10-24 12:20:45 EDT 
(In reply to comment #3)
> Seeing that M1 has crept up on me I am not going to push this in until M2. 
> I am thinking of not doing this at all for Kepler since it is looking like
> Kepler is shaping up to be more of a maintenance release from the framework
> perspective.

I have decided to drop this for Kepler since it is mainly being used as a maintenance release and I don't really want to remove function in a maintenance release.
Comment 5 Thomas Watson CLA 2013-05-06 09:56:30 EDT 
This has been done in the ongoing luna branch twatson/container.