[equinox-dev] customization approaches

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Hey Peter, 

Can you say more about your concerns?
 

By way of more context, the idea behind
the customization work is to reconcile difference in views between producers
and consumers.  Producers create code, markup, ... according to their
view of the world.  Consumers then take the bundles (in this case)
and compose them to make a system.  It happens frequently to us that
the consumer's view is quite different than the producers.  We can
say "too bad" or we can allow consumers to customize the product
to their needs.  Curently the main culprits in this area are plugin.xml
and manifest.mf and to a certain degree the code itself.  The proposal
here would allow people to contribute arbitrary transformation mechanisms
(xslt, sed, scripted, ...) and others to contribute arbitrary transformations
to be run by the transformers on particular kinds of product artifacts.
 

Note, while having the base mechanism
be quite open and general is cool, it also raises the bar on consumption
and gives "normal" people just a bit too much rope with which
to hurt themselves.  So the hope is that there will a simplifying
mechansim that makes the easy things easy (and safe) and helps people directly
address the usecases at hand (e..g., composing products from disparate
pieces)

Jeff

"Peter Neubauer" <peter@xxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/24/2006 03:01 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Incubator commit rights for Kim Horne

Hi,
while the whole concept sounds really cool, introducing the same
converting power to the XML parts of Equinox/RCP as e.g. byte code
manipulation or preprocessing to other code, I am a bit reluctant to
placing complex transformation logic into that layer. To me this
smells like we are approaching things like ANT, Jelly etc etc instead
of pulling up the logic into a layer that is better supported by
tools, e.g. Java, JVM scripting languages or some other DSL.

I'm not saying it is wrong to explore this track, but I at least have
been burned before by having part of the system declared in non
refactorable XML/XSL systems.

Cheers

/peter

On 10/24/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
>
> 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.
>
> Jeff
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev