equinox
exploring eclipse runtime possibilities

 
Mission Statement
The goal of the Equinox project is to experiment with techniques for broadening the range of Eclipse platform runtime configurations. For example, the Eclipse plugin model is static; there is no discussion of practices and tools for managing/reducing interplugin dependencies; service discovery is not covered and the component distribution mechanism is non-standard.

These issues do not severely impact the usefulness of Eclipse as a development tool platform but they do affect the use of Eclipse in more constrained environments (e.g., handheld devices, IT managed environments, mass-appeal applications etc.). The Equinox project will investigate such issues and develop approaches which are practical and applicable to the main Eclipse code base.

Scope

The Equinox work will focus on the following areas:

Dynamic plug-ins
Currently Eclipse uses a static plug-in model. When Eclipse is started it discovers the set of installed plugins and builds a plugin registry. This registry is then resolved and locked down. As a result, plugins cannot be added, removed or updated without shutting down and restarting Eclipse. In addition to being inconvenient for users managing their installation, certain workflows and usecase do not allow for shutting down and restarting the platform. Further, since plugins cannot be deactivated, the memory footprint of a running Eclipse grows monotonically as the user touches more and more function (i.e., activates more and more plugins). Equinox will unlock the registry and enhance the plugin lifecycle to allow dynamic plugin installation and removal/activation and deactivation.
Component management
Eclipse manages plugins, fragments and features using a mechanism written specifically for Eclipse. While simple and reasonably powerful, issues in the area of security/access and centralized configuration management all need attention. Equinox will look at various mechanisms and standards in this area (e.g., OSGi, JNLP, ...) and look at their integration with Eclipse.
Dependency management
One of the key aspects of Eclipse is the factoring of function into plugins. These plugins are then composed to form the technology base for a given domain. The Eclipse team has done an excellent job of keeping the dependencies between plugins relatively clean but still there problems creating minimal installs in various scenarios. Equinox will look at this fundamentally hard problem by exploring alternative factorings of existing plug-ins (e.g., the UI plugins) as well as programming practices and tools which support and foster the reduction and management of plugin dependency chains.
Services model
The extensibility of Eclipse is based on plugins and their interconnection via extensions and extension points. While powerful, this model can be constraining. For example, the UI plugins specify how people contribute menu entries but not how/if someone can replace the implementation of the UI itself. As a result, plugins are tied to the workbench UI or must have alternate implementations for differing UI bases. Note here that the UI domain is only one example, this problem surfaces in other places. Equinox will investigate alternate models of linking plugins together such as service discovery. It will not seek to replace the extension/extension point mechanism but rather to complement it.
Methodology

The Equinox project is primarily meant as an incubator for the Eclipse platform project. While the platform team is under no obligation to accept changes proposed by Equinox, the intention is that members of the platform team be involved in Equinox and that the models, mechanisms and implementations developed be immediately and obviously beneficial to the platform. To that end, the Equinox project will:

  • Track changes in the platform through frequent resynchronization.
  • Make available incremental and discrete changes so that the platform team can smoothly integrate new technology as it is developed.
  • Minimize API impact or propose migration paths where change cannot be avoided.
  • Produce largely working solutions.
  • Seek to use existing technologies and standards wherever possible/relevant.
  • Not support work items which have no hope of being integrated into the Eclipse platform.
Timeline
Equinox is starting just as Eclipse 2.1 development is ending. As such, the main focus will be on contributions to Eclipse 2.2 (4Q2003) with larger or breaking changes being directed towards subsequent/major releases. The expectation is that Equinox work be offered for integration into the platform as soon as possible.