Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-pmc] Re: [Fwd: slides to preview]

The transform bundles were originally implemented as a response to the 3.3 "Customization" plan item (described in bug 154099). They were placed in the incubator out of convenience - the problem space seemed to have better alignment with Equinox rather than UI and giving me Equinox commit rights at that point didn't make sense. The incubator allowed me to work on this problem without stepping on anyones toes - the fact that this code lives in the incubator is entirely a matter of expediency.

Although this plan item was ultimately deferred in 3.3 the code produced by the transforms work was sufficient to allow IBM teams (in the 3.4 timeframe) to investigate and implement UI reduction stories based on it. It's proven "worthy" (I hope) to be in the Equinox component proper.

If I was a member of the Equinox team I don't believe we'd be having this conversation - the bundles would simply be in the Equinox (or Equinox Bundles) component already. These bundles don't seem to fit the traditional incubator mould and the process around incubation (exemplified by the skeletal slide deck) seems too cumbersome to accommodate their use. These bundles are more akin to a traditional feature (developed by any Eclipse developer) than a true incubation project.

The lack of community is a consequence of what I mentioned above. There's no more a vibrant community around it than there is a vibrant community around the view extension point or the WorkbenchAdvisor - it's moreso a feature than a full on incubator project. Keep in mind there is probably less than 200-300 lines of code in these projects combined.

Let me address your concerns with regard to API. While there is no Java API being published in the traditional sense these bundles do in fact form an extensible framework rather than a fixed tool. It is possible to contribute your own transformer types via an OSGI service (registered on the Object class with a specific tag) as well as your own custom transform instances. It is not a closed system at this time, merely unconventional. Much of the reason for is a result of how Equinox framework extensions are laid out - the transformer hook is a fragment on top of Equinox and as such it makes it difficult to have a dependency on any class within it. So while the slides say there is no API, that isn't entirely the case. Take a look at for info on how the code can be extended. It's really quite easy.

I think this also addresses your framework concern. These projects really do constitute a framework. We have an abstract notion of a transformer (exemplified by the hook) and various transformer types that plug into it (XSLT, SED, and replace). Although we're emphaszing the XSLT transforms at this point they are by no means the only kind of transform that is interesting. The talk I was slated to give at EclipseCon with Ben Pasero (now being carried by Ben alone) shows a very compelling use of the replace transformer that enables complete skinning of an app. In no way is the usefulness of these bundles restricted to IBM products alone.

On 28-Feb-08, at 12:12 PM, Bjorn Freeman-Benson wrote:

Kim (committer), Jeff & Mike (eclipse.incubator project leads), and the Eclipse PMC, (cc/ Mike) Kim has requested that the Equinox Transforms Bundles graduate from the incubator to the main Equinox code line. Looking at the draft of the slides (attached), I see slide 5 - IBM/Rational is the only client - and slide 9 - there is only one developer, also from IBM/ Rational - and slide 8 - there is no API. • How can this be seen as having vibrant and diverse committer and adopter communities? ( and • And, without any APIs, how can this be seen as following the purposes of the Eclipse Foundation, e.g., "supplying frameworks" ( ; section 1.1) • Similarly, without any APIs, how does this have "balanced progress in creating both frameworks and tools" ( )? Could you clarify how this is a "common good" framework rather than code for a single company's products that just happens to be hosted at Eclipse?
Bjorn Freeman-Benson
Director, Committer Community
Eclipse Foundation

971-327-7323 (Pacific Time)
[end of message]<Equinox Transforms Review.pdf>

Back to the top