Equinox Migration Preview
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
Buy The Book
Equinox News