equinox
m2 plan 1630 June 17, 2003

 
M2 Plan

Our goal for the Eclipse 3.0 Milestone 2 is to do a first iteration implementation of the key elements in the RCP roadmap. The metagoal is to get enough implementation and understanding to allow the Eclipse team to commit to 3.0 plan items in this area. We will start with Eclipse 3.0 M1 as a base and pull in work previously done in the Equinox project and elsewhere. We fully recognize that some parts of the work will be disposable but seek to do the first iteration in an interative development approach rather than adopt a disposable prototype mindset.

The emphasis here is on an expression of the RCP concepts and challenges. Completeness (e.g., handling all special cases) is not required. Extraneous function or modification to the base Eclipse code should be avoided. The code we produce is, in effect, a specification of the changes we propose. Eclipse-knowledgeable people will be able to diff the Eclipse 3.0M1 code and the RCP M2 code and get a good understanding of the magnitude and character of these changes. Accordingly, contributors should assume they are writing a specification in which clarity, brevity and precision promote understanding and acceptance.

Dynamic plugins

Scenarios:

Dynamically enable a plugin: Implies adding it to the set of enabled plugins, and reresolving. Assuming it resolves, its extensions and extension points are added to the system. Notifications are sent to all interested parties. Interested parties include as a minimum, all plugins receiving extensions from the new plugin.

Dynamically disable a plugin that is not activated and has no activated dependents: Since the plugin is not active this implies removing the plugin from the enabled set and reresolving. On resolve the disabled plugin will be removed from the registry and its dependents transitioned to unresolved (i.e., also removed from the registry). Generate the required notifications and broadcast to interested parties. Interested parties include at least those plugins receiving contributions from the plugin(s) being disabled/unresolved.

Dynamically disable a plugin that is activated and/or has activated dependents: The plugin is removed from the enabled list and the registry reresolved. As a result, the disabled plugin and its dependents are removed from the registry (as they are either disabled or unresolved). The newly removed plugins must first be deactivated (see below). Following deactivation, generate the required notifications and broadcast to interested parties. Interested parties include at least those plugins receiving contributions from the plugin(s) being disabled/unresolved.

Dynamically deactivate a plugin: Given a plugin which is activated, be able to deactivate it. Deactivating the plugin should return it to the deactivated state (i.e., ready for activation) and free any resources allocated to it (e.g., classloaders, registered objects/handlers/listners, ...). Optionally, plugins which depend on the plugin being deactivated can be deactivated. If this is done, they should be deactivated in the proper dependent-first order. Introduce API to capture the deactivation events and notify interested parties. Interested parties include plugins receiving/providing extensions from/to or, optionally, dependent on the deactivated plugin.

Work items:

  • Incremental registry resolution. As plugins are enabled and disabled, the registry needs to be updated incrementally. The default behaviour for this should be one of "least perturbation". That is, when installing a new version of a plugin that is already active, replacement should be deferred until platform restart or forced by the user. This reduces the apparent shutdown and restart of plugins. The design must allow for alternate policies (e.g., "just do it", ...).
  • API for representing changes to the extension point structure and notifying interested parties of these changes. Depending on the change, certain parties will automatically (unconditionally) receive these notifications (as outlined). Others may programmatically register to receive these events.
  • Enable various plugins for dynamic behaviour. The runtime will, as outlined above, generate several new lifecycle events as a result of dynamic plugin behaviour. Various Eclipse plugins need to be updated to listen for these events and handle them accordingly. In practice we are only proposing that the Eclipse plugins which are part of RCP be "dynamicized" (e.g., JDT, PDE, ... need not be changed). The primary challenge will be the UI plugin. It presents a representative case and making it dynamic should highlight the issues and techniques in this area.

OSGi

OSGi is a hot topic in the Eclipse runtime area. The M2 goal is to explore the issues related to OSGi and be able to make a determination as to whether or not OSGi is a viable runtime. The issues range from relatively mundane implementation/structuring approaches to more fundamental design decisions. The implementation issues include:

  • Mapping an OSGi implementation onto the Eclipse install structure
    • do not copy bundles
    • allow running from expanded jars (for dev mode)
    • allow running from plugin jars (i.e., the jars from an update site) for the normal mode
  • Knit the OSGi implementation into the Eclipse boot structure
    • maintain the Eclipse command line arguments (as they make sense)
    • determine how to run the specified Eclipse application
    • splash screen
    • restart without "starting" all of the bundles from last time
  • Scaleability
    • Eclipse on OSGi should come up and perform roughly the same as it does currently

Within the OSGi organization a number of changes related to Eclipse are being proposed or discussed. The bulk of these are contained in OSGi RFP 44. The relevant items are listed here in priority order. For the M2 deadline we expect to have initial implementations for all P1 and P2 items. The P3 and P4 items are also required to reach our ultimate goal of merging the Eclipse and OSGi runtimes but by M2 we simply need to have a clear understanding of the solutions (e.g., sketches of RFC proposals), costs and risks for the different items.

  • Priority 1
    • 4.1.5 Code matching enhancements
    • 4.1.6 Relax constraints on presence of native libraries
    • 4.2.2 Bundle fragments
  • Priority 2
    • 4.1.8 Singletons
    • 4.2.1 Bundle as a module
    • 4.2.3 Export multiple versions of a package (and bundles)
  • Priority 3
    • 4.1.4 Enumeration of resources within a bundle.
      • need incremental discovery as some bundles have huge trees.
    • 4.2.4 Different package(/bundle) major versions incompatible
    • 4.5.1 Translation of manifest information
    • 4.1.7 Transactions spanning multiple life cycle operations
  • Priority 4
    • 4.2.5 Filter packages from Base Classloader
    • 4.2.6 Version overrides
    • 4.3.1 Demand loading of services from bundles
    • 4.4.3 Bundle signing

Security

Security is a major weakness of Eclipse. What is needed here is a review of our security options covering at least the items listed below. The choices and recommendations should be motivated by real RCP usecases. There is currently no compelling need to secure tooling related plugins like JDT, PDE or the resources model.

Given the possibility that the Eclipse and OSGi runtimes will be merged, it makes sense also to consider the security questions in the context of the security model and mechanisms provided by OSGi.

  • What are the performance ramifications of securing code
  • What mechanisms are available or can be provided to secure domain code?
  • What parts of the following Eclipse plugins/function needs to be secured?
    • Runtime
    • Update/install
    • UI
    • other?
  • How should we provide for user authentication?
  • Should the Eclipse runtime provide a general credential store?
  • Secure delivery (e.g., jar signing, RFP 44 item 4.4.3)
  • API impacts

Backward Compatibility

One of the key requirements on the new runtime work is that there be significant support for existing plugins. This support comes in the form of maintaining existing API and basic behaviours. It does not imply that, for instance, old plugins will suddenly be enabled for dynamic behaviour, or be secure. As the base requirement, we should be able to run the current Eclipse on the new runtime with the dynamic or security features disabled. API such as the IPlugin* must be retained but their implementations can be replaced. The backward compatibility facilities must be clearly identified by deprecating the relevant code.

Update/Install

Update/Install will be affected by the changes to the runtime but these changes will be minimal in the M2 timeframe. Only the changes needed to make the function work and understand any issues will be done. As such, the M2 implementation will, as much as possible, use the same install layout as Eclipse 3.0 M1. The runtime may require some additional files (e.g., bundle manifest) but these are non-contentious. The OSGi implementation will be designed to conform with the existing layout rather than imposing its own (see the items on running from directories etc). In the M2 timeframe we will continue to provide plugin.xml files with all the relevant information. Any additional or differently formatted information required by OSGi will be provided separately as appropriate. This allows the update/install view of the world to go on relatively unchanged.

The dynamic plugins work introduces the potential for update changes. For example, allowing users to enable/disable plugins from the update dialogs. Further, when the user installs a new feature/plugin the platform not longer needs to shutdown and restart (in most cases). The new plugins are resolved and made available and the platform configuration (both in memory and on disk) updated accordingly.

PDE

It is not a stated goal of the RCP work to modify/affect PDE. While some changes may be required, only the changes needed to make the function work and understand any issues will be done in the M2 timeframe. Given that we will continue to use the existing install/configuration layout, PDE should be able to start runtime workbenches with little change.

An obvious area of change is the use of bundle manifests. The M2 implementation will maintain parallel manifests, plugin.xml and MANIFEST.MF. PDE will continue to be used to manage the plugin.xml. The bundle manifest will be maintained manually by developers.