[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Replaceable OSGi runtime
|
Any news on the separate service bundle? I have also some comments inlined.
Thanks,
Gorkem
Jeff McAffer wrote:
Gorkem Ercan wrote on 11/03/2006 09:05:27 AM:
> 1. Services provided by the equinox, namely FrameworkLog,
> PluginConverter, PlatformAdmin, PluginConverter, BundleLocalization,
> Location, URLConverter, EnvironmentInfo are not specified in OSGi
> specifications and they should be available independent from equinox
> core. I guess there are several ways to provide that as interfaces to
> be provided by the replacing OSGi implementation or as a separate
> bundle that provides those in an equinox independent way.
Yup. This is what we are addressing right now. Your input on the
solution would be great. DJ will likely be posting some information
on this next week.
> 2.Startup initialization which initializes system properties and loads
> configurations from the file system needs to be taken out of
> org.eclipse.core.launcher.Main and
> org.eclipse.core.runtime.adaptor.EclipseStarter so that a replacement
> framework can call these initializations. This way, the initialization
> can be done easy without any further knowledge of the steps taken by
> Equinox.
Not sure I agree with you here. The setup of a framework currently is
not standard so Main and EclipseStarter are very particular to
Equinox. The properties and other configurations they setup are also
particular to Equinox. Some of the properties that are setup are used
by some of the Equinox framework services and should be set in a
fashion appropriate for each framework. For example, setting
osgi.configrution.area and osgi.instance.area may be different for
Felix, KF, Prosyst, ... Do you have some concrete examples of what
can/should be separated out?
I was thinking about a way to ensure that all the required
properties are initialized properly so that EclipseStarter would
delegate to framework specific initializer. I guess some documentation
can help with that as well.
> 3.The bundles should not assume that the org.eclipse.osgi bundle is
> the System Bundle so that it is possible to replace equinox bundle.
yes. This is a wide scoped issue. When you find a bundle that
requires org.eclipse.osgi you should enter a bug report against the
relevant team and advise them of the value of Import-Package in these
scenarios.
> Also there are other issues like what to do with the 2.0 compatability
> issues and the situation with the exploded bundles which are not
> really supported by OSGi spec.
2.0 compatibility?
Exploded bundles are certainly not spec'd (though I don't think the
spec prohibits them in any way) but all open source frameworks
currently support that form (as well as install by reference AFAIK).
This is really a framework implementation issue that we can't help
you with.
There are some osgi headers are generated out of plugin.xml I thought
this is due to compatability but I may be wrong. You are correct spec
does not prohibits them but they are always refered as bundle jars.
Jeff
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
