[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] customization approaches
|
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