equinox |
Summary | |
Moving Eclipse toward a Rich Client Platform raises the challenge for
installing/updating complex applications, managing the overall configuration
of the Eclipse environment and controlling sharing between applications
(plugins). As a platform to build one modular offering of complementary
products, Eclipse does wonder. In particular, it promotes great integration
frameworks (Workbench and Workspace) for a modular development
based on plugins, which translates into a modular deployment and updates.
However, the mechanisms in place for controlling sharing of plugins and the
flexibility of the overall configuration are challenged when
Eclipse is used as a shared platform for many large applications coming
from different providers.
This document introduces the notion of scopes to solve that problem.
Nota Bene: This document describes the scope model as intended for the current prototype, not the final decisions of Equinox. | |
Introduction | |
Moving Eclipse toward a Rich Client Platform, shared across providers, raises the challenge for installing/updating complex configurations. Controlling sharing between applications, in terms of bundles or plugins, becomes critical for the overall robustness of the platform as well as to promote applications interoperability. Unfortunately, the current Eclipse approach is inadequate. The design sweet spot of Eclipse is modular application suites, rather than a shared platform. Eclipse works very well for a provider to integrate a suite of applications. Complex applications can be built as modular assembly of plugins. Installs and updates are modular and therefore incremental. Even part of the platform may be updated incrementally. However, an integrator has to be very carefull in managing the potential integration conflicts between applications. Indeed, all plugins are shared in Eclipse. So plugins have to be all written in a way that support sharing between different applications. This is not a lightweight requirement for plugin programmers. Some existing Java code is not easily ammenable to being re-entrant. Furthermore, even if a plugin can be shared by design, different versions of applications may actually require different versions of the same shared plugins. We enter the difficult realm of concurrent loading of plugins. Eclipse have very limited capabilities for concurrently loading different versions of a plugin. It is limited to library plugins, that is, plugins without extensions or extension points. This is to avoid conflicts in the Eclipse registry between extensions and extension points from the different versions of the shared plugins. Also, Eclipse assumes a total abscence of side effects from the library plugins, allowing to load them concurrently. The goal of this document is to improve on the current Eclipse mechanisms for adequate control of sharing and overall configuration through the introduction of scopes. Scopes are fundamentally an encapsulation mechanism for application integrator. One major design requirement for scopes was to detect configuration problems at install/update time. This includes detecting unresolved components, potential class cast exceptions, and service conflicts. By expressing an assembly of Java components (see below for details), a scope is a point of control for consistency, which can be assessed at install time. Single scopes for applications are usually created by the application integrator. However, scopes can be nested in an acyclic directed graph, allowing for complex multi-application configurations. Nesting of scopes typically happens at install time, as an integral part of the installation process. For complete control, this strongly suggests a two-phase approach to intalling or updating components or scopes. The idea is to have virtualized installs and updates, allowing the administrator full introspection on the future effects of the changes he or she is applying. If these effects are not to his or her liking, the changes may be rollbacked. Otherwise, they may be commited and they will take immediate effect in the running platform. Scopes relate to the notion of assembly in Microsoft.NET, in the sense that both attempt to avoid DLL Hell. Poor controlling over sharing and configuration flexibility were at the root of the Microsoft DLL Hell. Microsoft.NET is addressing these root causes with assemblies, and we will compare our approaches. | |
Scope Model | |
To be included soon. |