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

Bug 361877

Summary:	Provisioning an Eclipse 4 application is difficult due to lack of explicit dependencies on DS and EventAdmin
Product:	[Eclipse Project] Platform	Reporter:	Brian de Alwis <bsd>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	bugs.eclipse.org, john.arthorne, Lars.Vogel, Mike_Wilson, mistria, oscarvarto, pascal, Peter_Weihrauch, remy.suen, t-oberlies, tjwatson
Version:	4.2
Target Milestone:	4.3 M6
Hardware:	All
OS:	All
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=424104
Whiteboard:
Bug Depends on:	313553, 324352, 412121
Bug Blocks:	362147

Description Brian de Alwis

2011-10-24 22:10:09 EDT

Provisioning a pure Eclipse 4 application is too difficult at the moment, for two reasons.

First, Eclipse 4 now depends on OSGi Declarative Services, but we have no mechanism to express this dependency. As a result, developers waste time trying to understand why their apps do not work. Currently we report an error message to the console log if DS is not found, but unfortunately this error is easily missed.

We need a mechanism such that p2 or PDE's validate wizard can determine that DS is required and either provision DS or report an error. One possible solution here might be to exploit the fact that org.eclipse.equinox.ds exports org.apache.felix.scr — a set of annotations intended to be used at runtime to auto-generate service descriptions; I'd hazard that Felix's DS implementation exports this package too. We could have org.eclipse.e4.core.di add an Import-Package on org.apache.felix.scr. It's a bit of a hack, unfortunately, as these annotations are only used at build-time, and not runtime, and are optional. Alternatively we could see if p2 could be augmented to record metadata for Service-Component entries found in bundle manifests.

(I should note here that we are not the only component with this issue: p2 itself requires DS and fails with a rather oblique error if it's not available.)

Second, we do not provide a feature that provides the fundamental base bundles required to provide the Eclipse 4 application platform. The Eclipse 3.x platform provides the org.eclipse.rcp feature (cf http://wiki.eclipse.org/Eclipse_RCP_How-to#Feature). We do have org.eclipse.e4.rcp feature, presumably intended to be analogous to org.eclipse.rcp, but it is incomplete: it is missing key bundles, including Declarative Services (org.eclipse.equinox.ds) and Equinox Events (org.eclipse.equinox.event), as well as a number of supporting bundles such as Batik. Interestingly, org.eclipse.rcp has been updated for the Eclipse 4.x stream to incorporate the compatibility layer, and actually includes the org.eclipse.e4.rcp feature.

I'd suggest that we change org.eclipse.e4.rcp to be self-sufficient for a pure Eclipse 4.x application, and remove the overlapping bundles from org.eclipse.rcp.

(These issues are being encountered by prospective developers, e.g., as reported in the e4 forum at <http://www.eclipse.org/forums/index.php/mv/msg/246581/737042/>)

Comment 1 Brian de Alwis

2011-10-24 22:15:27 EDT

I guess the org.eclipse.rcp features are still in CVS?

http://git.eclipse.org/c/platform/eclipse.platform.releng.maps.git/tree/org.eclipse.releng/maps/rcp.map

Comment 2 John Arthorne

2011-10-25 09:12:58 EDT

Tom, I know the discussion has come up before about specifying a dependency on DS. I don't like the idea of importing an implementation package for this, but I can't remember if we came up with any other way to do this.

Comment 3 John Arthorne

2011-10-25 09:14:15 EDT

(In reply to comment #1)
> I guess the org.eclipse.rcp features are still in CVS?

Yep, the map files don't lie! That one hasn't been migrated yet.

Comment 4 Thomas Watson

2011-10-25 10:35:18 EDT

(In reply to comment #2)
> Tom, I know the discussion has come up before about specifying a dependency on
> DS. I don't like the idea of importing an implementation package for this, but
> I can't remember if we came up with any other way to do this.

We could add a capability to the org.eclipse.equinox.ds that other bundles could depend on.  The OSGi alliance is currently discussing standardizing a namespace that could be used for such a purpose, but we could invent our own in the mean time if we would like.  I suspect it would look like this header in the org.eclipse.equinox.ds bundle:

Provide-Capability: 
 equinox.extender; equinox.extender="osgi.ds"; version:Version="1.1"

This indicates that the equinox.ds bundle provides an extender implementation type of osgi.ds at specification version 1.1.  A bundle which has a ds component description could specify the following Require-Capability:

Require-Capability: 
 equinox.extender; filter:="(&(equinox.extender=osgi.ds)(version>=1.1)"

This indicates that the bundle requires an extender capability of type osgi.ds at specification version 1.1 or greater.

But we need help from p2 to support these headers (see bug313553 and bug324352) otherwise you will still get errors at runtime, only difference is the bundles that require a ds implementation will no longer resolve because of a missing requirement.

Comment 5 John Arthorne

2011-10-25 11:12:03 EDT

Brian, can you open a separate bug for the suggested feature refactoring so we can focus this one on the DS issue?

Comment 6 Brian de Alwis

2011-10-27 00:00:08 EDT

(In reply to comment #5)
> Brian, can you open a separate bug for the suggested feature refactoring so we
> can focus this one on the DS issue?

Filed as bug 362147.

Comment 7 Paul Webster

2011-11-14 10:18:40 EST

*** Bug 363565 has been marked as a duplicate of this bug. ***

Comment 8 Brian de Alwis

2011-12-08 11:22:04 EST

I should add that org.eclipse.equinox.event is another dependency that is not explicitly required.

Comment 9 Paul Webster

2011-12-19 10:55:58 EST

*** Bug 367083 has been marked as a duplicate of this bug. ***

Comment 10 Thomas Watson

2012-03-15 13:53:46 EDT

(In reply to comment #4)
> We could add a capability to the org.eclipse.equinox.ds that other bundles
> could depend on.  The OSGi alliance is currently discussing standardizing a
> namespace that could be used for such a purpose, but we could invent our own in
> the mean time if we would like.  I suspect it would look like this header in
> the org.eclipse.equinox.ds bundle:

To give an update on this.  OSGi has defined a namespace (osgi.extender) that can be used by extenders to provide a capability which extendees can then depend on (i.e. declarative services).  But we still need to wait for an update to the declarative services specification that defines what the osgi.extender namespace value will be for declarative services (osgi.ds or osgi.component or ...).

But none of this helps unless others are willing to get bug313553 and bug324352 fixed in p2 to support the generic dependencies.

Comment 11 Brian de Alwis

2012-05-09 12:40:19 EDT

Updated the title of this bug.

Comment 12 Brian de Alwis

2012-05-09 12:42:45 EDT

*** Bug 378975 has been marked as a duplicate of this bug. ***

Comment 13 Brian de Alwis

2012-05-09 13:36:08 EDT

Given that users are stumbling into problems (bug 378975), we're going to introduce explicit dependencies on org.eclipse.equinox.ds and .event as a temporary workaround (bug 379023), to be removed once the right approach is in place.

Comment 14 John Arthorne

2012-06-26 10:30:30 EDT

*** Bug 378975 has been marked as a duplicate of this bug. ***

Comment 15 Pascal Rapicault

2012-08-31 23:54:23 EDT

I just noticed the bug dependency on the p2 bug about support for generic capabilities and I would like to understand what it is that you are trying to express that you can not do at this point.

Comment 16 Lars Vogel

2013-02-20 08:47:47 EST

I think this one is closed org.eclipse.e4.rcp contains all required bundles except the EMF one, but these are listed as dependencies in org.eclipse.e4.rcp.

Closing as fixed, please re-open if you disagree.