RE: [eclipse-pmc] Equinox Transforms graduation [was Re: [Fwd: slides to

["Philippe Ombredanne" <pombredanne@xxxxxxxxx>]

Bjorn: Kim:
Just to add my 2 cents to the fray ... :-)

On the topic of community adoption:
The very nature of the transforms is that it is akin to some fundamental
API, and as such does not has the opportunity to grow a community an
isolation. It is also something that had the bad luck to just work pretty
much out of the box. Hence probably the little feedback it got. I use it and
it is awesome and did not need to provide feedback on it whatsoever.
My bad, and probably other users bad!
It is so awesome in fact that it is the only clean way I know to act as "the
hand of god" on existing Eclipse plugins and APIs: IMHO this is an essential
tool that every adopter that makes some serious packaging of Eclipse-based
products should be using and abusing ( instead of ugly hacks and patches
that were required before.) You can redirect some APIS invocations, remove
some more, remodel the UI, and so on as needed, without the need to
explicitely patch the core code that exposes or consume those APIs.
Kim: feel free to me /nexB as adopters in the review document.

On the topic of APIs:
Equinox Transforms are a kind of meta-API, and Kim you could  may be explain
it as such?
It is about being able to transform the APIs and redirect APIs invocations
at load time. 
What the Transforms does is really just installing hooks that enable
transforms. 
The API of that meta API could be expressed as the ways to add transforms
via those hooks. 
The subject of the Transforms are API themselves, not as defined in the
Transforms per se, but instead as defined by every plugin that would expose
an API. The meta nature makes it hard to grasp at first, but IMHO the result
is elegant and powerful, and again a tool every Eclipse product builder
should adopt.


--
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
-----Original Message-----
From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Wednesday, March 05, 2008 9:52 AM
To: Kimberly Horne
Cc: eclipse-pmc@xxxxxxxxxxx; emo@xxxxxxxxxxx
Subject: [eclipse-pmc] Re: [Fwd: slides to preview]


Kim, (cc/ Jeff, McQ, Mike, the Eclipse PMC)

They were placed in the incubator out of convenience - 
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. 

That may be true, but they *are* an incubation component and the community,
through the Board of Directors, has told me/the EMO to follow a certain
process regarding the graduation of incubation projects. The process isn't
for me (if it were entirely up to me, the process would be a different
thing, trust me) -- the process that the EMO has the thankless job of
enforcing is for the larger Eclipse community. The larger Eclipse community
has told me/us that it wants vibrant communities and frameworks, etc. You
may see this is just a stupid hoop to jump through, but the larger Eclipse
community has, repeatedly, told me that it wants this documentation from the
projects for each review. Feel free to encourage your Board representatives
(the one IBM rep and the five Committer reps) improve the process in the
future.

The lack of community is a consequence of what I mentioned above.  
So you need to explain this to the larger community in your slide deck.
Perhaps the "there are only 200 lines of code" is the best explanation.

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.  
Great - again, you need to explain this to the larger Eclipse community via
your slide deck. Just saying "there is no API" raises huge red flags: we
(the EMO) are simply prohibited by the Bylaws from approving any project
review for a project that has no API.

If you'll provide a new slide deck that explains these points to the larger
Eclipse community (these same items that you've just explained to me), then
we'll be good to go.

- Bjorn

-- 
[end of message]