Equinox Transforms Tooling

We will be adding tooling (of some flavor) in 3.4 that will allow product developers to better utilize Equinox Transforms. This tooling would attempt to allow for an easy solution the following common customization issues.

• extension element removal
  • removing views
  • removing keybindings
  • removing menus and actions
  • removing primary wizard declarations
  • etc...
• extension attribute change
  • renaming views
  • re-binding keybindings to alternate keys
  • changing action set default visibility
  • changing target id for menu/action extensions (moving menus)
  • etc...
• extension element moving
  • re-ordering items within a menu extension
  •  ??
• manifest alteration
  • update bundle version
  • update compatibility range
  • update import/export declarations
• replacing/adding bundle files
  • informal patches (class file replacement)
  • image skinning

Solutions

The solution to these issues requires more than one type of transform. The majority of the extension transforms can be covered by XSLT transforms although some (the menu target id changes) might be more simply accomplished via a sed transform. Similarly, manifest alterations would be easily handled by sed and finally the replacements are clearly mapped to replacement transforms.

The shape of this tooling is currently up in the air but will likely resemble one of the following solutions:

PDE Integration

This solution would see additional tooling added to the existing Product editor, likely in the form of a new page entitled Customization. In its most simple form we would present a tree containing all extensions and resources contained within bundles destined for the target. This tree would allow for in place editing of extensions (renaming and deletion) and would somehow facilitate replacement of bundle resources directly (via drag and drop?).

Additionally, once customizations have been made the required changes to the config.ini and VM arguments can be managed automatically.

Pros:

• seems a natural place to put this
• easily integrate into the build/deployment process. Deploying transforms is tricky by virtue of their implementation and the more seamless we can make it the better

Cons:

• PDE team buy-in. This work is being undertaken by the UI team and is quite sizable in scope. Contributing such a large body of work is often fraught with complications.
• Because the transforms are on a target product rather than the running Eclipse it's still conceptually difficult to figure out what exactly it is you're doing. The product developer still needs to map from extension particulars to what it is in the target environment they're trying to remove.

UI Integration

This solution would allow product developers to customize their currently running environment. A plug-in would be installed that would raise a special dialog with something akin to a "record" button. When invoked, this button would render any further interaction in the workbench ineffectual. Instead, when elements in the workbench are invoked or selected the user would be presented with a further dialog asking what the user would like to do with this item. Options would be specific to the selection made but would likely involve remove and rename. When the record button is pressed once again the workbench is returned to normal operation and the user may export their changes. In addition to arbitrary locations on the file system the transforms could also be emitted to the running instance itself and after a reboot the changes would be reflected for the user to see.

Pros:

• slick.
• in addition to solving the product developer problem it can also be used by power users to solve their particular issues
• doesn't require PDE buy-in - built on top of the UI directly.
• possible integration with the PDE Spy?

Cons:

• product developer must have a built instance of their product before customization can occur
• doesn't help with deployement - developer still needs to tweak their target configuration and ini files to accomodate the changes in any deployed instance of their product
• mapping from contribution to extension may require additional API. IPluginContribution helps but there is no guarentee that non-platform extension points make use of this interface.
• full scope of transforms may not be possible (how do you articulate class file replacement in this scenario?)
• once removed how do you return to your previous state? Do we have rollback options in the UI?