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