[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Replaceable OSGi runtime
|
The runtime options document was something I have not noticed before
thanks for pointing that. We are fine with working with scenario 1.
--
Gorkem.
Jeff McAffer wrote:
Gorkem Ercan wrote on 11/15/2006 04:35:33 PM:
> Any news on the separate service bundle? I have also some comments
inlined.
There have been some disruptions in the work flow here but all seems
to be back to normal barring illnesses etc.
> Jeff McAffer wrote:
> > 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.
We are currently not planning on initializing the properties for you.
For example, we have no idea what the osgi.configuration.area should
be for Felix of KF. All of the system properties are documented in
the Help.
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html
There are really two scenarios.
1) The Equinox service implementations included in the supplement
bundle can look at the properties and use them as normal. In this
case people are expected to set the appropriate properties such that
our services can pick them up.
2) We in fact only publish the service API and/or people simply
implement their own version of the service. In general the services
we are talking about are very simple so this is somewhat realistic.
Does this make sense to you?
> > 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.
Can you be specific here? The plugin.xml is now (for the past two
releases) used only for populating the Extension Registry service.
So, if you are referring to the automatic conversion of old plugins
(ones that do not have manifest.mf), we do not intend to support that
legacy mode of operation on other frameworks. Of course, you might
want to do that yourself but I would seriously question why. In
general we are not planning to support any of the backward
compatibility capabilities on other frameworks. We do expect that
most will work without a fuss and we will certainly consider
contributed patches as necessary but we will not be actively pursuing
that usecase.
Jeff
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
