DSDP/RTSC - Problems migrating to Eclipse 3.6
In the context of Eclipse a RTSC product is defined as a bundle containing RTSC packages, Eclipse features/plugins and miscellaneous files(like docs, release notes). A RTSC product is used in the Eclipse platform by users to consume content shipped as RTSC packages.This page discusses the current product architecture of a RTSC product and problems seen while migrating to the Eclipse 3.6 platform. The objective is to come up with a product architecture that will be well supported in current and future Eclipse platforms and discuss solutions to support existing RTSC products in the Eclipse 3.6 platform.
A RTSC product currently ships all of its content - Eclipse plugins/features, docs, RTSC packages -in one bundle that is installed on disk. The Eclipse plugins/features are shipped in an extension location that is located in the top level folder of the product. This organization makes it convenient to manage multiple side by side installs of the product. One of the key requirements for a RTSC product is that it should be possible to use any version of a installed product for application build in Eclipse. To achieve this goal the Eclipse plugins shipped with the product are split into two - (a) a tools plugin that is used for build (b) an UI plugin that contributes to the Eclipse UI. The Eclipse platform loads all the available tools plugin but only the latest version of the UI plugin. This ensures that the users gets the benefits of the latest product UI integration but can choose any version of XDCtools for application build.
This division of plugins is managed by controlling the version number of the plugins. The tools plugins have a unique id which is made up by concatenating the productId - a unique id for the product - with the product version number. The UI plugin always has the same plugin id - the productID. The plugin version for both the plugins is the same as the product version. This division however puts the onus of carefully managing the backwards compatibility of the UI plugins on the product developer.
The Eclipse feature id is managed in a way to provide patch updates to major product releases via the Eclipse update manager. The feature id is incremented only when major releases of a product is made.
Problems with migrating to Eclipse 3.6
We have faced several problems while migrating to the eclipse 3.6 platform.
- Undocumented rules are used for loading plugins. For example one of our features used the includes element to include another feature.This resulted in the platform loading just the tool plugin for the product while the UI plugins where ignored. This caused a major problem while upgrading to newer releases of a product. While users where expecting to use the latest version of the UI plugins they were getting the earlier version. Removing the includes element in the feature worked around this problem.
- The new P2 update mechanism is particularly problematic. The Eclipse 3.2 update manager downloaded the product installer defined in the data' element of the feature. This element is ignored by Eclipse 3.6 update(P2). Our features currently specify a custom install handler via the install-handler element of the feature. This mechanism is not supported in P2 - which provides the alternate mechanism of touchpoints. We want to maintain one update site that works for both P2 and Eclipse 3.2 and this compatibility break is forcing us to maintain separate features for the purpose of update.
- UI support for registering extension location has been removed
- APIs used for registering extension locations are marked as deprecated with no alternate APIs being provided.
Discussions with community members
We would like to discuss the following issues with the community members
- Eclipse platform roadmap for supporting extension locations
- RTSC product architecture that works well with the current and future evolution of the Eclipse platform
- Rules used by P2 for loading plugins from extension locations.
- Resolving current product update issues with P2