| Re: [equinox-dev] customization approaches |
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@xxxxxxxxxxx10/24/2006 03:01 AM
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx> 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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev