The 3.3 plan
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html
has an item related to customization
https://bugs.eclipse.org/bugs/show_bug.cgi?id=154099
Kim Horne (UI team) has been investigating
some techniques for transforming plugin.xml files and thus the registry
contributions they contain. Basically this amounts to a mechanism for spec'ing
an XSLT style sheet and then running the plugin.xmls through the transformer
as they are loaded. See
http://wiki.eclipse.org/index.php/Product_Customization
Kim has offered to contribute
this to Equinox. Pretty cool. But wait, it gets better.
When you stand back from those details,
it appears that there are several other things that could be "customized".
Manifest.mf for one. Code for another. The Equinox incubator
already includes a work area related to Aspects. The proposal here
is that the scope of that work be broadened to include transformation of
other artifacts. In addition to the specific transformation mechansms
discussed, Kim would like to investigate a customization brokering service
that would match transformers to transformations and transformees. This
notion would, for example, allow for a manifest customization mechanism
to be plugged in. Ideally we would also be able to phrase code customization
using this mechanism. This may involve AspectJ weaving or some other
mechanism (e.g., for mapping class references when packages are renamed).
In any event, all of these things are
in the Equinox domain and Kim is offering to drive at least part of this
effort. To facilitate that, I propose adding Kim as a committer on
the Equinox Incubator component. Please respond to this list with
your votes.