felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject RE: Felix Product Plugin and/or Initial Provisioning Service?
Date Wed, 15 Mar 2006 02:58:06 GMT
"Rick Litton" <Rick.Litton@ktd-kyocera.com> wrote on 03/14/2006 12:34:05 
> Pardon my ignorance on initial provisioning...but are you referring to
> the Eclipse Plug-in Architecture?  If so, adoption of this architecture
> is a major shift in current Oscar or Felix thinking.  For one thing,
> reconciling the bundle manifest with the Equinox version is a major
> undertaking.  Regards.

As a point of interest, can you clarify how you are differentiating the 
Eclipse plugin architecture from the OSGi bundle model?  Eclipse plugins 
ARE OSGi bundles and Equinox is a standalone implementation of the OSGi R4 
spec.  It is true that Eclipse adds a couple of additional headers to the 
manifest and we have a mess of additional services but for the most part 
these headers can be (and are) safely ignored when running on non-Equinox 
frameworks and the additional services, like any service, can be either 
reused or re-implemented as needed.

I don't want to over sell anything here.  The reality today is that most 
Eclipse bundles will not run on other existing OSGi frameworks.  This is 
either because a) other frameworks do not fully support R4 (fragments and 
require-bundle figure heavily in Eclipse) or b) some of the Eclipse 
codebase makes implementation assumptions about the framework (Equinox). 
The former is changing as Felix and Knopflerfish work towards R4 
completeness.  The latter is still evolving.  The Eclipse codebase is 
large and we are reworking individual bundles as the need/demand arises. 
In general the Equinox bundles are are clean of Eclipse assumptions.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message