Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/RTSC - Problems migrating to Eclipse 3.6"

(Introduction)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
In the context of eclipse a RTSC product is defined as a product shipping RTSC packages, miscellaneous content along with eclipse integration features/plugins. 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. Also solutions are required to support our existing products in the Eclipse 3.6 platform.
+
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.
  
 
== Product Organization ==
 
== Product Organization ==

Revision as of 18:54, 19 November 2010

Introduction

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.

Product Organization

A RTSC product currently ships all of its content - eclipse plugins/features, docs, RTSC packages -in one folder. The eclipse plugins are shipped in an extension location that sits in the top level folder. This organization makes it convenient to manage multiple side by side installs of the product. One of the requirements of using XDCtools in eclipse is that it should be possible to use any version of XDCtools 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 load 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 productUI 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 developer.

Another aspect of a product is the feature id. The feature id is managed 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 products. While users where expecting to use the latest version of the UI plugins they were getting the earlier version. Removing the includes element got rid of 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 update manager and this compatibility break is forcing us to maintain separate features for the purpose of update.

  • UI support for registering extension location have been removed
  • APIs used for registering extension locations are marked as deprecated with no alternate APIs being provided

We have seen some rich discussions on the support for extension locations in the community but there is no indication on the future direction of the platform.


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
  • Solving product update issues with P2

Back to the top