Community
Participate
Working Groups
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/>)
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
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.
(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.
(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.
Brian, can you open a separate bug for the suggested feature refactoring so we can focus this one on the DS issue?
(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.
*** Bug 363565 has been marked as a duplicate of this bug. ***
I should add that org.eclipse.equinox.event is another dependency that is not explicitly required.
*** Bug 367083 has been marked as a duplicate of this bug. ***
(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.
Updated the title of this bug.
*** Bug 378975 has been marked as a duplicate of this bug. ***
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.
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.
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.
