Bjorn Freeman-Benson schrieb:
The
Foundation requires certain behaviors, encourages others, and lets the
projects flourish on other axises. It would be a mistake to have a
single controlling entity insisting that everything be done "The One
Way" where there is so much energy, enthusiasm, creativity, and talent
amongst our committers and members. I believe that one of the big keys
to open source success is "openness" - the ability to let go of certain
decisions and let those closest to the facts control the direction.
Alright, so we assume the Eclipse community as a whole can afford the
energy-waste of Eclipse projects competing against each other, instead
of working together. After all, the biggest competition remains outside
the Eclipse community (or even the Java community), and it surely is
confusing for newcomers to be confronted with competing approaches to a
common problem.
>
This is really sad to hear about, as it is a precedence of substantial
> fragmentation to occur among eclipse technology sub-projects.
I will say that it is disappointing, but it is not wrong and not a
problem. Having two teams investigate similar issues from different
approaches has certain benefits - for example, we get to compare and
contrast two different approaches and then choose the best one. It has
certain disadvantages as well - for example, if their approaches are
similar, then one team's work may be "wasted" when it does not become
the commonly accepted package.
It seems that the friction is a continuation of the EJB 3.0 vs. JDO 2.0
dispute, where it was, at least in my opinion, rightout sad to see that
"political", i.e. marketing issues, dominate the former side over
technical reason. Not wanting to cooperate or not even wanting to
communicate to me clearly is unreasonable and rings the same bell for
me. I personally find it sad because technical reason momentarily is
defeated in a first big incident within the Eclipse community visible
to me.
I think we should get past the "why are there two ORM projects?" issue
and work on the ORM technology - as Robert said "in the end there [will
soon be] a solution ... for ORM in Eclipse and for today that is really
what is important.".
Right. To contribute a little to possible differentiation and
competition, isn't it that EJB 3.0 currently does not specify execution
outside a managed environment? I mean, they have it as a goal, but, as
far as I know, as of today there does not exist any common specified
API that is implemented by different vendors. At least
ejb-3_0-dr2-spec-persistence.pdf has to say about
2.9 APIs for Obtaining and Using an EntityManager in
non-J2EE Environments
[Note to readers] This area will be addressed in the next draft of
this specification.
So, to note something differentiating that is important "for today", EJB
3.0 currently cannot be used on the client side, i.e. it currently
cannot be used for applications based on the Eclipse Rich Client
Platform, while JDO 2.0 (jsr220-orm) can. Given that this is
not even specified yet in EJB 3.0, it will still take some time once it
is until there will exist any reliable implementations.
|