I'll contribute the "I'm feeling
lucky" transformer!
Jeff
Kimberly Horne <kim@xxxxxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
10/26/2006 02:48 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] customization approaches
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.
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)
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