Re: [equinox-dev] replaceable OSGi runtime again

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Danail Nachev wrote on 03/05/2007 12:21:35 PM:

> Currently, this bundle contains a classes, which enable registry
> deployment on frameworks different than Equinox. I wonder at what
goal
> this bundle aims:
> - support Equinox bundles (registry, preferences, etc.). In other
words,
> this bundle will support the bundles which are developed in Equinox
project
> - support bundles initially written for Equinox. In other words, enable
> the deployment of a bundle, which was developed on Equinox framework
and
> later deployed on another framework.
> 
> If the bundle aims at the second goal, then I think that there are
> packages which should be included in the supplement bundle. Those
are
> the public packages (not marked with x-internal or x-friends directives)
> exported by org.eclipse.osgi bundle (such as
> org.eclipse.osgi.framework.eventmgr and
> org.eclipse.osgi.service.environment). Because their use isn't
> discouraged, the chance that they will be used is big.

I agree that it is a little ill-defined.  In
practice it is a mix of the two cases.  We want to ensure that the
various Equionx bundles/services run on other suitable frameworks. We also
want to enable bundles written on Equinox and using Equinox facilities
are able to to run on other frameworks.  We *also* want to support
cases where bundles such as the registry are running without *any* OSGi
framework.

One of the key distinctions is in how a particular
service is implemented or situated.  For example, you mention the
environment service.  Like any other service, people are free to supply
their own implementation of this service.  On Equinox it happens that
there is a built in implementation because the Equinox framework itself
uses the service.  Others (e.g., Felix, Prosyst, ...) are free to
integrate such a service in their framework or write and supply a separate
bundle that registers such a service.  In some cases the implementation
of such a service might be closely coupled with the framework so only the
framework implementors are in a position to supply the implementation.
in other cases there are existing stories (e.g., logging) and people may
want their service to tie into that story.  Again, we are not in a
position to supply that implementation.

> Another question here is, which exactly bundles
are planned to be
> available on other frameworks (assuming that the target framework
> implements all needed OSGi features)?
> ...

We are interested in having all our bundles run on
any applicable framework.  For example, with OSGi r4.0.1 we have almost
all the things needed at the framework level.  It would be great to
have someone looking at ensuring that the various Equinox (and Eclipse)
bundles run fine on other 4.0.1 compliant framework implementations.  If
you find problems, please enter bug reports (with patches or solutions
preferrably :-)

Jeff