Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 345790

Summary:	Delete composite bundle API and implementation
Product:	[Eclipse Project] Equinox	Reporter:	Thomas Watson <tjwatson>
Component:	Framework	Assignee:	Thomas Watson <tjwatson>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	john.arthorne
Version:	3.7	Keywords:	api
Target Milestone:	Luna M1
Hardware:	PC
OS:	All
Whiteboard:

Description Thomas Watson

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

2012-06-25 11:40:52 EDT

We can now delete this.

Comment 2 Thomas Watson

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

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

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

2013-05-06 09:56:30 EDT

This has been done in the ongoing luna branch twatson/container.