[
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 http://wiki.eclipse.org/Equinox_Transforms
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? (http://www.eclipse.org/projects/dev_process/development_process.php#6_3_Reviews
andhttp://www.eclipse.org/projects/dev_process/development_process.php#6_3_2_Graduation_Review)
• And, without any APIs, how can this be seen as following the
purposes of the Eclipse Foundation, e.g., "supplying frameworks" (http://www.eclipse.org/org/documents/Eclipse%20BYLAWS%202003_11_10%20Final.pdf
; section 1.1)
• Similarly, without any APIs, how does this have "balanced
progress in creating both frameworks and tools" (http://www.eclipse.org/projects/dev_process/development_process.php#6_3_Reviews
)?
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
voice:
971-327-7323 (Pacific Time)
email:
bjorn.freeman-benson@xxxxxxxxxxx
--
[end of message]<Equinox Transforms Review.pdf>
