While I've put a lot of thought into the XSLT solution for various use cases the scope of what I'd like to do in the incubator is more generalized as Jeff has already mentioned. I dont want to tie us down to any one solution. Ideally it'll be possible to plug in any transformer(XSLT, vanilla java, random number generator) you'd like.On Oct 25, 2006, at 2:45 AM, Peter Neubauer wrote: Sorry for the spam, hit the send button too early ....
Hi Jeff,
I understand the rationale o customisation, but I am very burned out of XML based systems that place interceptors, business logic, class names, JDBC urls etc etc into XML based scripting languages, XSLT and what not in order to achieve things that are much more powerful when applied via proper (scripting) languages and adaptors.
Couldn't the same be achieved by instead working on approaches that eliminate the need for predefined artifact types outside the OSGi (even better java) world, such as for instance defining a programmatic interface to the registry and hooks for interceptors, so other bundles can (a secured) way intercept plugin and manifest contributions to the registry and adapt them to whatever they want using whatever input they want, may it be XML if people think that is maintainable over time? That way, we could avoid adding one more paradigm to the mix for Joe programmer, we keep things type safe and leave it to the interceptor implementer to choose his or her intercepting input technique.
Then, patching the plugin.xml/Manifest.mf to adapt to different target extension name spaces is IMHO just a symptom of lacking specification for e.g. the workbench Extension points. It would be nice to define them in a Eclipse agnostic way and mechanism, maybe through a combination of OSGi service id and service configuration.
I guess what I am coming down to is that a proper interceptor/AOP mechanism for Equinox/OSGi is the more sustainable way to go in order to deal with these problems.
This is just my gut feeling so take it for what it is.
Cheers
/peter
On 10/24/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
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
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
_______________________________________________ equinox-dev mailing list |
