Skip to main content

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 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
  • - 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.


  1. 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.
  2. 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.contenttype
Equinox News feed

Back to the top