equinox
equinox documents
[home]
[framework]
[bundles]
[incubator]
[documents]
[downloads]
[faq]
This document details the major changes in the Eclipse runtime layer (aka Equinox) during the 3.2 development cycle.
Runtime Split
The Runtime has been refactored as per https://bugs.eclipse.org/bugs/show_bug.cgi?id=113663.
The refactoring was done to:
- provide extension registry that could be used independently form Eclipse and/or
OSGi
separate Registry, Jobs, Preferences, and Content into stand-alone portions to
simplify re-use
-
make the runtime more flexible
As a result of the refactoring, several new plugins have been added:
- org.eclipse.equinox.common - portions that are needed by more than one piece
of the former runtime plugin (i.e. IPath, IStatus, IProgressMonitor). This
should be useful as a common base for a standalone JFace as well as using the
Registry without OSGi.
-
org.eclipse.equinox.registry - Extension registry
-
org.eclipse.equinox.preferences - Preferences mechanism
-
org.eclipse.core.jobs - Jobs mechanism
-
org.eclipse.core.contenttype - Content mechanism
-
org.eclipse.equinox.supplement - A supplemental "plug-in"
that is used to support running without OSGi.
These changes should have no affect on other plugins.
Adapting
- Conflicts with new public APIs. org.eclipse.equinox.common includes several
new API classes (e.g., Assert and ListenerList) that have common names. Code
which use import com.example.* to import classes by these
names and import org.eclipse.core.runtime.* now have abiguous class references
at compile time. Organizing the imports and choosing the appropriate import
source should resolve this problem.
-
Explicit classpaths in the build scripts. As a result of the code being
moved into new plugins, custom scripts that explicitly reference org.eclispe.core.runtime
need to add one
or more
of the following as appropriate:
- org.eclipse.equinox.common
- org.eclipse.equinox.registry
- org.eclipse.equinox.preferences
- org.eclipse.core.jobs
- org.eclipse.core.contenttype