equinox
Prototype Roadmap

 
Summary

This first prototype of the Eclipse Rich Client Platform is the result of the work of Olivier Gruber and Woody Huang, both at IBM T.J. Watson Research Center. This prototype is based on Eclipse RC3, in which OSGi has been integrated. It demonstrate a full dynamic stack: OSGi, dynamic plugin registry, and dynamic Workbench. This document describes the roadmap for this prototype.
Last Modified: 1400 June 21, 2003


Nota Bene: This document describes the current prototype, not the final decisions of Equinox.

Introduction

This document discusses the roadmap for this RCP prototype. While it shows a complete vertical stack of a dynamic RCP, based on OSGi and Eclipse, it is still in need of much work. The self-hosting architecture needs to be revamped, for a cleaner and more suited approach. The OSGi layer itself needs some more work, introducing security along with minor functionality improvements. The Eclipse registy also needs some improvements, including some API changes for making it secure. Finally, some of the integration plugins (Workbench and Workplace) need some more work too.

Self-Hosting Roadmap

The self-hosting architecture needs to be revamped, for a cleaner and more suited approach. This includes minor evolutions of the architecture (boot, runtime, and update plugins) as well as straightforward changes to the PDE tooling (especially the launcher). The overall idea is ensure that Eclipse works as a plugin layer above a standalone OSGi environment.

Today, Eclipse architecture does not encapsulate much of the internals of the platform. First, plugins dive down in Boot plugin, reaching for static methods for various information and support. Second, the Boot plugin also provides some support to posting Runnable, and thereby provide a single-point of management for handling exceptions. Third, Boot provides a URL framework, as an internal package but that is used throughout Eclipse. Fourth, Boot also contains specific support for a PlatformConfiguration without encapsulating properly the plugin store internals.

Bundle Store Encapsulation
OSGi advocates a strong encapsulation of the bundle store, regarding both code and data. This is not only for security reasons but also to hide internal implementation details, helping for portability of applications. This impacts the overall API to the Eclipse platform.

This requires a clean API to access bundle contents. It probably needs to work hand-in-hand with the URL framework, which needs to be moved to the OSGi URL framework as specified in OSGi, release 3.0. Also, since bundle contents may be large, we need to introduce a visitor pattern in the API for accessing bundle contents.

Cleaning-up Boot
The overall Boot support has to be cleaned up and moved as an OSGi service: reaching to static methods in the Boot plugin is not an acceptable approach anymore.

Also, the implementation has to be cleaned up of redundancies. There is right now two mechanisms for many things such as logging, debug facilities, or tracing facilities. It would be nice to have a clean merged approach.

Another issue is the support in Boot for runnable and exception handling. Again, this needs to be surfaced as an OSGi service. This is tightly related to issue of batching processing and the overall multi-threading architecture.

Also, we need to integrate the persistent storage for bundles/plugins. We also have two mechanisms there (meta-area and bundle data). This is clearly not something to decide by PDE. This suggests to have clean notion of target instances, with their own storage for the bundles, plugins, metaarea, and other metadata.

Update Manager
The overall idea is to have OSGi encapsulate the code and data store— no more direct plugin drop-in. A host Eclipse would manage target OSGi environments and use a push-down approach to deploy bundles. In other words, PDE launcher would trigger a push on the update manager of the specified OSGi target. This approach supports persistent configurations, allowing to debug the life-cycle code for plugins (startup and shutdown). It also leverages the hot install and update capabilities in the target, avoiding to rely solely on the hot-class-updates in the JVM.

This suggests to revisit PlatformConfiguration in Boot. In particular, there is no reason to maintain in Boot a concept of features and sites, which are not known to the rest of the runtime platform.

Detailed Self-Hosting Items
Prioritized list of items to work on. P1 is immediate priority, it is a problem to fix or a missing functionality. P2 priority is a bit more relax, it is important but not critical for moving Equinox forward. P3 priority is about would-be-nice items.

  • [P1] Move Boot URL framework to OSGi URL framework.
  • [P1] Introducing API to access bundle contents (RFP-44-4.1.4)
    • Based on URLs and visitors? Need incremental discovery as some bundles have huge trees.
    • Can we reuse some parts of the resource plugin API?
      • Hide file system classes ?
      • Contents read only? If not, dangerous self hosting !!!
      • If not read-only, do we need to generate change deltas.
  • [P2] Fix how Eclipse is started, PDE self-hosting, allowing for persistent configuration
    • command line arguments
    • role of Eclipse applications
    • splash screen
    • prechecks
    • remove PlaformConfiguration
    • adapt Eclipse update manager and the dependencies on it.
    • merge metaarea and bundle private storage
    • leverage OSGi configuration and preference management
  • [P2] Update manager
    Adapt current update manager to the presence of bundles. Adapt features also. Define relationship between features and scopes.
    • Move update manager to OSGi level (robustness and usability)
    • No more direct knowledge of the on-disk format. Use an API to install bunbles.
    • Attempt to remove dependencies on the update manager through the UI.
    • Cleanup/remove PlatformConfiguration from Boot plugin
    • Ensure update manager can handle legacy plugins (see Backward compatibility story)
    • Revisit overall product install from InstallShields and how it will leverage the update manager: no more direct plugin drop-in.
  • [P3] Cleanup redundancy for debug, tracing, logging.
  • [P3] Cleanup Boot, move all static support to an OSGi service.
  • [P3] Enhancing PDE tooling
    • Generating bundle manifests (import/exports, bundle identity, etc.)
    • How do we generate the buildpath in terms of bundles/plugins?
    • Better self-hosting through a push approach
        Allows for hot updates
      • Support non-transient configuration
      • Host Eclipse as a local plugin site
    • Look to the SMF Bundle developer tooling (in WSDD) for code, examples, help, development effort.

OSGi Roadmap

The current OSGi implementation is partial. We focused on the core support needed to run Eclipse, that is, bundles and services. Here is a list the functionality of the OSGi specification that we left out.

  • Plug&Play architecture
  • Security
  • Configuration management
  • Permission administration
  • User administration
  • Preferences

Also, the implementation needs more work, mostly regarding a better support of Eclipse requirements.

[P1] Activation Model
The current Eclipse "automagic" activation of plugins on classload is problematic. It causes concurrency problems. Plugins are activated on class load not on class initialize. Many classes are loaded due to verification efforts rather than attempts to actually run them. There are no standard hooks for discovering widespread class initialization. To change this dramatically changes the programming model and many plugins which uses static fields initialized through the Plugin activation. Before thinking about changing this, we need to find a clean model. Right, we hacked a support for running the current Eclipse plugins.

  • We need declarative services to avoid starting bundles to register services
  • Automated activation: class load and service lookup
  • Unified activation between OSGi bundle start and plugin startup.
  • Restart without restarting all of the bundles from last time (not the same as transient bundles)
  • Batching support, hide Thread class.

Events
Events may be costly if not batched through deltas. The events for services as well as extensions are not batched yet. A negative performance impact has to be confirmed first, and if confirmed, deltas need to be introduced.

  • Service events, delta per bundle
  • Extension events, delta per plugin providing extension points

Introducing Scopes
The introduction of scopes aims at providing a mechanism for controlling sharing in complex configurations, thereby avoiding DLL Hell. Besides the scope model itself, we need to decide really quickly if we have multiple versions visible at a programming level. The current prototype is inconsistent in that regard since OSGi promotes a single-version model while Eclipse registry promotes a multi-version model. Through scopes, multi-version is made possible and visible to the administrator of the platform, but bundle/plugin developers do not see multi-versions.

We believe the programming model should not expose multi-versions.

Detailed OSGi Items
Prioritized list of items to work on. P1 is immediate priority, it is a problem to fix or a missing functionality. P2 priority is a bit more relax, it is important but not critical for moving Equinox forward. P3 priority is about would-be-nice items.
  • [P1] Fix Activation model across layers.
  • [P1] Move to a reified design and more explicit reflection API for installing or updating bundles.
  • [P1] Fragments
    • Ensure standalone OSGi layer by adding fragment info to bundle manifest
    • enforce no-activator, or coordinate the activation sequence
    • enforce that the fragment services appear as services from its master.
  • [P1] Introducing matching criterion on imports
  • [P1] Optimize cycle support in matching imports/exports
    • Interning all string when parsing manifests
    • Using a flag for declare/undeclare instead of actual removal
  • [P1] Local optimization for electing provider, not the highest version.
  • [P2] Filter packages from Base Classloader (RFP44-4.2.5)
    • Filter out ClassLoader (need to extend Bundle interface)
    • Filter out Thread (see activation model)
  • [P2] Robustness regarding bundle reclaimation (class loader, classes, and objects).
  • [P3] Relax constraints on presence of native libraries (RFP-44-4.1.6)
  • [P3] Caching of resolved state on shutdown. Reloading on restart
  • [P3] NLS & OS/ARCH/WIN support

Eclipse Registry Roadmap

Here is a status about the plugin registry. The plugin manifest has not been changed to reflect those changes. It would need changing PDE and also the parser. This needs to happen fast. Also, the implementation of the registry was not easily ammenable to dynamism; there are quite some modifications to do. The registry is however a very straightforward data structure, so the real challenge is to maintain some sort of backward compatibility.

When including security concerns and dynamism, this suggests to have a strict interface-based API to the registry. Removing any access to any internal of the Plugin registry. Hence probably breaking backward compatibility. Fortunately, very few plugins shall be dependent on the internals of the plugin registry.

Detailed Plugin Registry Items
Prioritized list of items to work on. P1 is immediate priority, it is a problem to fix or a missing functionality. P2 priority is a bit more relax, it is important but not critical for moving Equinox forward. P3 priority is about would-be-nice items.

  • [P1] Finish virtual installs/updates, missing full reflection API
  • [P1] Programmatic adding/removal of extensions and extension points?
  • [P1] Plugin Deactivation
    • API for initiating plugin deactivation
    • API/lifecycle notification events for broadcasting plugin deactivation
    • Infrastructure for helping plugin writers manage their inter-plugin references etc so they can clean up on deactivation of one of their prerequisites or contributors.
    • Allow for deactivation veto or for optionally staying active when a prerequisite is deactivated
  • [P2] Revisit the entire implementation, the current one is to exposed (security) and not suited for dynamic behavior
  • [P2] Add permissions to define extensions or extension points.
  • [P3] Impacts of scopes on the Eclipse registry ?
  • [P3] Do we still need the notion of singleton?
  • [P3] Optimisation of events about extension life cycle (limiting overhead such as redrawing in Workbench. Deltas— deltas au niveau du plugin/bundle
Workbench & Workplace Roadmap

To be included soon...

Introducing Security

There are several aspects to security: user authentication, credential store, mechanisms for securing code and the application of these techniques to the appropriate parts of Eclipse. Certain elements are essential for securing an RCP.

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

Test Cases

We need test Cases for OSGi and Eclipse Registry Layers.

  • Testing bundles & fragments resolution & updates
  • Testing extensions and extension points matching
  • Testing two-phase install
  • Testing extension-related events