[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] replaceable OSGi runtime again


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