The OSGi Alliance is busy working on the next release of the specification.
The release of the next OSGi specification will be long after the Eclipse
3.4 (Ganymede) release. To achieve a stable Ganymede release we will not
release new OSGi R4.2 API or implement new R4.2 functions in the
Hi. This conversation is best suited for the newsgroup, so I have started
a thread there. The following is the same reply as posted in the
newsgroup:
Simple answer: You are right in that currently you would have to augment
getMBeanInfo in your derived Contribution class to return the set of
Thanks for the clarification. Suggested terms
- deferred install or staged install
- sequenced install
I am not happy with the term following deferred or sequenced. People
may read too much into it (e.g., does sequenced updating sequence installs
too?). perhaps * operation.
Jeff
Pascal
There is no technical problems with building out of a branch or the
incubator (except that we would have to run the build separately since
there would be two bundles with the same BSN and therefore two map entries,
etc.).
In the end I was just curious about your intentions.
Wrt to the actual
At this point I do not think we intend on doing a major overhaul on the
framework. I can only see us doing that if 1) it is evident that the
current implementation is not fulfilling the Eclipse usecases which are
important to the Eclipse community as a whole 2) The OSGi specification
changes are
Another possibility is split phase install for the case of separating
the download from the configuration. This follows the engine terminology -
it's really splitting the phases into separate invocations of the engine.
That term would also capture any situation where the phases are broken
