Equinox Migration Preview
This document details the major changes in the Eclipse runtime layer (aka Equinox) during the 3.2 development cycle.
Runtime SplitThe 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.
- 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
of the following as appropriate: