Jump to: navigation, search

Product Customization

Revision as of 14:09, 13 October 2006 by Kim Horne.ca.ibm.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

See bug 154099 for the plan item that corresponds to this page. The problems discussed here can be thought of largely as transformation problems and wherever possible a solution along those lines is proposed.

Problem: Extension Grooming

It is often the case that RCP developers or even product packagers would like to include specific extensions from plug-ins but are are unable (or unwilling) to include all of the extensions. There are various reasons for this, such as: context menu bloat, gratuitous (and harmful) startup extensions, collisions in identifier namespaces (two "Navigator" views), or any number of other issues that make elegant integration impossible. In the RCP scenario there are similar concerns such as including only a subset of views (ie: Outline view but not Problems), including the workspace components without the IDE baggage, including Java model support without any (or a minimal subset) of the user interface. Because there are so many ways in which developers may want to censor or augment the extensions contributed by plug-ins a general solution may be applicable.

Solution 1: XSLT

One such solution is introducing into the extension registry the ability to apply XSLT stylesheets to plugin.xml files prior to their being parsed.


  • the sky is the limit - the possibilities for modification are virtually endless
  • XSLT is a reasonably well-known and understood technology


  • some scenarios would be prohibitively difficult to achieve using XSLT alone. For instance, changing externalized strings would require not only the XSLT transformation but also fragments containing new properties files in which the new strings would reside
  • God Mode - the potential for mistake (and abuse) is high and the difficulty in tracing and reporting problems is very high

There are several ways in which this support could be implemented.

Implementation 1: System Properties

The simplest way would be to look for particular system properties as a bundle is read by the extension registry. The system property could be globally applicable or somehow qualified by the bundle identifier. If found, the value of this property would be resolved into a location on the file system that contains a stylesheet. If found, the sheet is applied to the bundle.


  • simplicity - the implementation for this is trivial
  • easy to experiment with - removing this support should it prove unfeasible would be easy


  • no tooling support. Adding the system properties would be a manual affair that would somehow need to be added to the product launch. Takes the customization out of the product itself and makes the successful product launch dependent on launch setup (which isn't necessarily unreasonable)

Implementation 2 : Manifest Directives

When loading a non-fragment bundle check for the presence of fragments who's manifests contain a XSLT header. If present, that header is parsed and the resulting transformation is applied to the host bundle (and optionally all fragments).


  • conceptually similar to a patch


  • easy for 3rd party plug-in authors to subvert other vendors plug-ins by providing a fragment in their namespace
  • possibility for multiple fragments to each provide XSLT transforms. Which one wins?
  • not able to supply global transforms in this way without some expensive searching - ie: finding all bundles with a global XSLT manifest directive

Implementation 3: Transformation Service

Create an (optional) OSGi service that is consulted by the registry that is capable of providing transformations for plug-in.xml.


  • concept possibly extendable to other problems
  • possibly has the best tooling support. Concrete Java APIs to follow and extend


  • heavyweight and (compared to other options) time consuming to implement

Problem: Manifest Updates

It's possible that an application wishes to alter the manifest headers of its various component bundles. It might be something as trivial as renaming the bundles (for whatever unwholesome reason) or as interesting as changing the version range of required bundles (when they were specified in error or too conservatively).

No solutions presented at present although an generalization of Implementation 3 of the XSLT solution of the Extension Grooming problem above might be interesting.

Problem: Class File Updates

It's possible that an application wishes to reuse certain code but is unable to do so due to critical bugs. Given the source code the application provider is able to fix these bugs but is hesitant/unable/unwilling to repackage the problematic bundle directly. It would be nice to be able to patch the class libraries of bundles with updated versions of classes to address such scenarios.

No solutions presented at present although an generalization of Implementation 3 of the XSLT solution of the Extension Grooming problem above might be interesting.