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
apa
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
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 locat
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
P
I would like to publish a build of org.eclipse.osgi for OSGi R4.2. But
that question is orthogonal to where the code lives. We can build out of
the incubator or out of a branch, right?
It is a good question though. I'm not sure where we would publish the
build on the Equinox download site. I
Do you have plan to publish builds of what will be developed?
PaScaL
|>
| From: |
|>
>--|
|Thomas Watson <[EMAIL PROTE
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 Ganymede
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
att
For context the item that Jim initially quoted came out of the questions
section of the wiki (http://wiki.eclipse.org/Equinox_p2_Plan). This section
list questions that we need to answer by the end of M3 to decide what we
deliver in 3.4 will look like. The download before the installation is not
on
