Product Customization - GSOC release

This is the time for small summary. I hope Product Customization is about to became part of Eclipse. There is some work to do and there is some work already done. Big thanks to my GSOC08 mentors Kim and Chris for their support.
There are :

• Remove features from tree (Views, Commands etc.. - in general all IPluginElements / IPluginExtensions if you are familiar with the PDE Product model)
  
• Changing name of nodes.
  
• Launching product with transformations
  
• Exporting product with transformations
  

available. If you want to see it in action or read in detail please go to my GSOC blog.

If you ever had to extend an inherited or undocumented Eclipse based application, weren't you wondering what might be hiding in it? Myriads of misterious extension points and handy services. Since Eclipse 3.4 it's easy to deep dive into Eclipse extension points and services thanks to PDE Plug-in Registry view.



But as most of Eclipse based applications use Eclipse 3.3 or even 3.2, now it's getting easier to use Plug-in Registry in those older releases too, thanks to this bug.
Following screenshot presents 3.4 Plug-in Registry view installed in IBM Rational Software Modeler, based on Eclipse 3.3. Revealed are all GMF editors tool palettes with their IDs and names, which makes it easy to add even more tools!

EditingSupport + TreeViewer

On of the product customizations I work on is changing name of the object at tree. The first idea sounded quit reasonable for me so I've started implementing it as in place editor for tree items. one thing I found interesting was: "Since 3.3, an alternative API is available, see ViewerColumn.setEditingSupport(EditingSupport) for a more flexible way of editing values in a column viewer." so I've decided to get it a chance.

DISCLAIMER: I won't take any responsibility of you implementing editing in viewer this way. In fact I hope some of you will show me the right way.

So I have a tree viewer with "default" column which is a tree.
Each column editor (including TreeViewer has editElement method which can be used for editing n'th column for a given element). But it doesn't work cause you need a cell editor for given column. How this is provided ? Via EdditingSupport.
EditingSupport need to be associated with given column, so we need a column. Ok but column apart of having editing support need to have label provider set up. The label provider it needs is an CellLabelProvider. Oh dear can we then reuse our ILabelProvider, IFontProvider etc.. we had by the moment ? Yes, and no. There is one wrapper label provider WrappedViewerLabelProvider but unfortunately with the package access. So to reuse it in 3.4 you must copy the code.
That's all ?? Almost. If you are ok with the default firing the editor (on left mouse click, for programmatic actions or tab moving) it's all (well you need also some code for keep you column of proper size, but that's detail). I need to have editor fired only on my programmed events. To say how the editor should be fired provide EditorActionStrategy for the view.
So how it look like:

TreeViewerEditor.create(fTreeViewer, new NameEditorActivationStrategy(fTreeViewer), ColumnViewerEditor.DEFAULT);
fLabelProvider = new ExtensionCustomizationLabelProvider(getCustomizationInfo(), toolkit);
column.setLabelProvider(new CustomizationViewerLabelProvider(fLabelProvider));
column.setEditingSupport(new NameEditingSupport(fTreeViewer));


where NameEditorStrategy, ExtensionCustomizationLabelProvider, NameEditingSupport are my custom implementations of objects I've mentioned before.

And as I have said before: I really hope there is an easier way.