equinox |
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 pluginsScenarios: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:
OSGiOSGi 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:
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.
SecuritySecurity 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.
Backward CompatibilityOne 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/InstallUpdate/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. PDEIt 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. |