[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Incubator commit rights for Kim Horne
- From: "Peter Neubauer" <peter@xxxxxxxxxxx>
- Date: Tue, 24 Oct 2006 09:01:03 +0200
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mwTyp0/7ISYnHAfqYuAH4DeW/UKQ6mgM+dRebupmnNPnqcc/N/3Qiv5shqLi1s/aNT6/9feafvKtFb5VZ9lnLny0aFVOOq1BFQH8tHrTWZDt8oJaoVcrGuvpwp3bA4nMEwtPp+hEateqc2p6kuNZGtnaH9mjEu4ZutuoixRrGHU=
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.
On 10/24/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
The 3.3 plan
has an item related to customization
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
Kim has offered to contribute this to Equinox. Pretty cool. But wait, it
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.
equinox-dev mailing list