Eclipse Community Forums: Eclipse Foundation » Re: arent there now 2 official EJB3 Projects?

Help

Home

Home » General (non-technical) » Eclipse Foundation » Re: arent there now 2 official EJB3 Projects?

Show: Today's Messages :: Show Polls :: Message Navigator

Re: arent there now 2 official EJB3 Projects? [message #22694]

Mon, 01 August 2005 16:33

Eclipse User

Originally posted by: joerg.von.frantzius.artnology.nospam.com

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
[Crossposted from eclipse.technology.ejb-orm, subject is the overlap
between ejb-orm and jsr-220 projects]<br>
<br>
Robert Greene schrieb:
<blockquote cite="middcefnm$4vo$1@news.eclipse.org" type="cite">
<pre wrap="">This question of overlap and working together also came up in the JSR220-ORM
projects Creation Review. I will tell you the same answer I gave the review
committee. I think it would be best to have a single project. We attempted
to participate in an open forum discussion moderated by other companies to
see where we could work together . I laid out the entire scope of what we
were doing publicaly and suggested ways we could collaborate and to my
disappointment never received even a single response in the open forum or
otherwise. Not even a response that said, "thank you for your offer, but
we respectfully decline any involvement together". Instead, we got
absolutely zero response. Hard to work as a single community towards a
single solution with that level of communication. So, we continued forward
building our own community and tooling which will be released shortly.
</pre>
</blockquote>
This is really sad to hear about, as it is a precedence of substantial
fragmentation to occur among eclipse technology sub-projects. <br>
<br>
Does the eclipse technology PMC have knowledge of this, namely Bjorn
Freeman Benson? Is there nothing that can be done about it? Has there
been any action taken on behalf of the PMC to consolidate the two
projects into one? If yes, why did it not succeed, and if not, is there
any reasoning behind it or has this potential for fragmentation been
simply overlooked?<br>
<br>
Hoping for reason to come back in here,<br>
Jörg.<br>
<br>
<blockquote cite="middcefnm$4vo$1@news.eclipse.org" type="cite">
<pre wrap="">
Regards,

Robert Greene
JSR220-ORM Project Lead
<a class="moz-txt-link-abbreviated" href="mailto:rgreene@versant.com">rgreene@versant.com</a>

"Christian Sell" <a class="moz-txt-link-rfc2396E" href="mailto:christian.sell@netcologne.de"><christian.sell@netcologne.de></a> wrote in message
<a class="moz-txt-link-freetext" href="news:08bd344afb788abaacb8c30016122973$1@www.eclipse.org">news:08bd344afb788abaacb8c30016122973$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Maybe this is the opportunity to explain what exactly is the difference
between this project and the jsr220-orm project, which was also accepted
recently? The only difference I can see is the already contributed code
and the participants..

thanks,
Christian

</pre>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
<br>
</body>
</html>

Report message to a moderator

Re: arent there now 2 official EJB3 Projects? [message #22738 is a reply to message #22694]

Mon, 01 August 2005 16:59

Eclipse User

Originally posted by: rgreene.versant.com

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C5967F.C87D1220
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Jorg,

From my perspective, I would say that the bottom line is that it is a =
question of the degree of control . The Eclipse foundation is not a =
controlling body as much as a governing one that establishes process. A =
subtle difference. As I see it, while the foundation encourages =
collaboration and unity amoung projects, it does not enforce it. So, at =
times these things will occur. So as much as I too am disappointed, in =
the end there is still a solution ( even 2 ) for ORM in Eclipse and for =
today that is really what is important. =20

Robert Greene
JSR220-ORM project lead
rgreene@versant.com

This is really sad to hear about, as it is a precedence of substantial =
fragmentation to occur among eclipse technology sub-projects.=20

Does the eclipse technology PMC have knowledge of this, namely Bjorn =
Freeman Benson? Is there nothing that can be done about it? Has there =
been any action taken on behalf of the PMC to consolidate the two =
projects into one? If yes, why did it not succeed, and if not, is there =
any reasoning behind it or has this potential for fragmentation been =
simply overlooked?

Hoping for reason to come back in here,
J=F6rg.

Regards,

Robert Greene
JSR220-ORM Project Lead
rgreene@versant.com

"Christian Sell" <christian.sell@netcologne.de> wrote in message
news:08bd344afb788abaacb8c30016122973$1@www.eclipse.org...
Maybe this is the opportunity to explain what exactly is the =
difference
between this project and the jsr220-orm project, which was also accepted
recently? The only difference I can see is the already contributed code
and the participants..

thanks,
Christian

=20

=20

------=_NextPart_000_0009_01C5967F.C87D1220
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Jorg,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>From my perspective, I would say that =
the bottom=20
line is that it is a question of the degree of control .  The =
Eclipse=20
foundation is not a controlling body as much as a governing one that =
establishes=20
process.  A subtle difference.  As I see it, while the =
foundation=20
encourages collaboration and unity amoung projects, it does not enforce=20
it.  So, at times these things will occur.  So as much as =
I too=20
am disappointed, in the end there is still a solution ( even 2 =
) for=20
ORM in Eclipse and for today that is really what is=20
important.    </FONT></DIV >
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Robert Greene</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>JSR220-ORM project lead</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:rgreene@versant.com">rgreene@versant.com</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>This is really sad to hear about, as it is a precedence of =
substantial=20
fragmentation to occur among eclipse technology sub-projects. =
<BR><BR>Does the=20
eclipse technology PMC have knowledge of this, namely Bjorn Freeman =
Benson? Is=20
there nothing that can be done about it? Has there been any action taken =
on=20
behalf of the PMC to consolidate the two projects into one? If yes, why =
did it=20
not succeed, and if not, is there any reasoning behind it or has this =
potential=20
for fragmentation been simply overlooked?<BR><BR>Hoping for reason to =
come back=20
in here,<BR>J=F6rg.<BR><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<BLOCKQUOTE cite=3Dmiddcefnm$4vo$1@news.eclipse.org type=3D"cite"><PRE =
wrap=3D"">Regards,

Robert Greene
JSR220-ORM Project Lead
<A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:rgreene@versant.com">rgreene@versant.com</A>

"Christian Sell" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:christian.sell@netcologne.de"><christian.sell@netcologn=
e.de></A> wrote in message
<A class=3Dmoz-txt-link-freetext =
href=3D"news:08bd344afb788abaacb8c30016122973$1@www.eclipse.org">news:08b=
d344afb788abaacb8c30016122973$1@www.eclipse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Maybe this is the =
opportunity to explain what exactly is the difference
between this project and the jsr220-orm project, which was also accepted
recently? The only difference I can see is the already contributed code
and the participants..

thanks,
Christian

</PRE></BLOCKQUOTE><PRE wrap=3D"">

</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0009_01C5967F.C87D1220--

Report message to a moderator

Re: arent there now 2 official EJB3 Projects? [message #22826 is a reply to message #22738]

Tue, 02 August 2005 01:12

Bjorn Freeman-Benson

Messages: 334
Registered: July 2009

Senior Member

> Does the eclipse technology PMC have knowledge of this, namely Bjorn
> Freeman Benson?

I do indeed know about this as does the entire Technology PMC and the
EMO staff. Various actions were taken, but in the end the two projects
chose to work separately.

Robert was very correct in his statement:

> From my perspective, I would say that the bottom line is that it is a
> question of the degree of control . The Eclipse foundation is not a
> controlling body as much as a governing one that establishes process.
> A subtle difference. As I see it, while the foundation encourages
> collaboration and unity amoung projects, it does not enforce it.

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.

But I'm getting a little off-topic: the point here is whether this two
ORM projects situation is sad:

> 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.

> So, at times these things will occur.

This is not the first instance in even Eclipse's short life, but it
certainly is the most public.

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.".

-Bjorn

Report message to a moderator

Re: arent there now 2 official EJB3 Projects? [message #22870 is a reply to message #22826]

Tue, 02 August 2005 02:33

Eclipse User

Originally posted by: bob.objfac.com

+1

Competition is real. Competition is good.

http://jroller.com/page/bobk?entry=eclipse_is_not_apache

Bob

Bjorn Freeman-Benson wrote:
> > Does the eclipse technology PMC have knowledge of this, namely Bjorn
> > Freeman Benson?
>
> I do indeed know about this as does the entire Technology PMC and the
> EMO staff. Various actions were taken, but in the end the two projects
> chose to work separately.
>
> Robert was very correct in his statement:
>
> > From my perspective, I would say that the bottom line is that it is a
> > question of the degree of control . The Eclipse foundation is not a
> > controlling body as much as a governing one that establishes process.
> > A subtle difference. As I see it, while the foundation encourages
> > collaboration and unity amoung projects, it does not enforce it.
>
> 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.
>
> But I'm getting a little off-topic: the point here is whether this two
> ORM projects situation is sad:
>
> > 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.
>
> > So, at times these things will occur.
>
> This is not the first instance in even Eclipse's short life, but it
> certainly is the most public.
>
> 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.".
>
> -Bjorn

Report message to a moderator

ejb3-orm currently not usable for RCP (Rich Client Platfom) applications, jsr220-orm is [message #22912 is a reply to message #22826]

Tue, 02 August 2005 11:02

Eclipse User

Originally posted by: joerg.von.frantzius.artnology.nospam.com

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bjorn Freeman-Benson schrieb:
<blockquote cite="middcmh9c$82u$1@news.eclipse.org" type="cite">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.
<br>
</blockquote>
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.<br>
<blockquote cite="middcmh9c$82u$1@news.eclipse.org" type="cite">>
This is really sad to hear about, as it is a precedence of substantial
<br>
> fragmentation to occur among eclipse technology sub-projects.
<br>
<br>
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.
<br>
</blockquote>
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.<br>
<blockquote cite="middcmh9c$82u$1@news.eclipse.org" type="cite">
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.".
<br>
</blockquote>
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 <br>
<blockquote><b>2.9 APIs for Obtaining and Using an EntityManager in
non-J2EE Environments</b><br>
<i>[Note to readers] This area will be addressed in the next draft of
this specification.</i><br>
</blockquote>
So, to note something differentiating that is important "for today", <b>EJB
3.0 currently cannot be used on the client side</b>, i.e. it currently
cannot be used for applications based on the Eclipse Rich Client
Platform, <b>while JDO 2.0 (jsr220-orm) can</b>. 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.<br>
<br>
<br>
</body>
</html>

Report message to a moderator

Re: ejb3-orm currently not usable for RCP (Rich Client Platfom) applications, jsr220-orm is [message #22958 is a reply to message #22912]

Tue, 02 August 2005 14:11

Max Rydahl Andersen

Messages: 233
Registered: July 2009

Senior Member

> vendors. At least ejb-3_0-dr2-spec-persistence.pdf has to say about

Please read the public draft and not the out-dated dr2.

"5.2.2.2 Obtaining an Entity Manager Factory in a J2SE Environment"

> 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.

This is not true, and please note that JSR220 is called EJB3, not JDO.

There exists at least two implementations of this and more to come.

So, in short: EJB3 can be used on the client side today.

/max

Report message to a moderator

Re: ejb3-orm currently not usable for RCP (Rich Client Platfom) applications, jsr220-orm is [message #23001 is a reply to message #22912]

Tue, 02 August 2005 14:59

Eclipse User

Originally posted by: rgreene.versant.com

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C59738.1A70F3E0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

Hi Jorg,

The latest draft specification of JSR220 does define how it will work =
outside of a managed environment. There is a bootstrap class called =
javax.persistence.Persistence that is used to get ahold of an =
EntityManagerFactory. There are now 4 implementations in preview form =
that I am aware of available either commercially or through open source.

Regards,
-Robert

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=20

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.

------=_NextPart_000_000C_01C59738.1A70F3E0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Jorg,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The latest draft specification of =
JSR220 does=20
define how it will work outside of a managed environment.  There is =
a=20
bootstrap class called javax.persistence.Persistence that is used to get =
ahold=20
of an EntityManagerFactory.  There are now 4 implementations in =
preview=20
form that I am aware of available either commercially or through open=20
source.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-Robert</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">Right.=20
To contribute a little to possible differentiation and competition, =
isn't it=20
that EJB 3.0 currently does not specify execution outside a managed=20
environment? I mean, they have it as a goal, but, as far as I know, as =
of=20
today there does not exist any common specified API that is =
implemented by=20
different vendors. At least ejb-3_0-dr2-spec-persistence.pdf has to =
say about=20
<BR>
<BLOCKQUOTE><B>2.9 APIs for Obtaining and Using an EntityManager in =
non-J2EE=20
Environments</B><BR><I>[Note to readers] This area will be addressed =
in the=20
next draft of this specification.</I><BR></BLOCKQUOTE>
<DIV>So, to note something differentiating that is important "for =
today",=20
<B>EJB 3.0 currently cannot be used on the client side</B>, i.e. it =
currently=20
cannot be used for applications based on the Eclipse Rich Client =
Platform,=20
<B>while JDO 2.0 (jsr220-orm) can</B>. Given that this is not even =
specified=20
yet in EJB 3.0, it will still take some time once it is until there =
will exist=20
any reliable implementations.<BR></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000C_01C59738.1A70F3E0--

Report message to a moderator

correction: EJB3 is specified for use outside of a J2EE container [message #23044 is a reply to message #22958]

Tue, 02 August 2005 15:29

Eclipse User

Report message to a moderator

Re: correction: EJB3 is specified for use outside of a J2EE container [message #23088 is a reply to message #23044]

Tue, 02 August 2005 15:48

Max Rydahl Andersen

Messages: 233
Registered: July 2009

Senior Member

> There exists at least two implementations of this and more to come.
> Could you tell what these implementations are?

The two I know is JBoss/Hibernate EntityManager
(entitymanager.hibernate.org) and Oracle
(http://www.oracle.com/technology/ejb3/index.html).
Others here can probably list more (I saw Robert mention 2 more)

> So, in short: EJB3 can be used on the client side today.
> Given that the relevant part of the spec is only 1 month old, I doubt it
> a bit
> that "today" here really is today as in 8/2/2005...

Well, I'm running it here ;)

> Do you know of any RCP application, or some other client application
> with a GUI,
> that makes use of it? For JDO 2.0, I know at least of one in production
> use. We
> created that one using JPOX, though, not VOA.

No, I don't know of any RCP application using EJB3 nor JDO2 (before the
one you just mentioned).
But I know of a couple that uses Hibernate with Eclipse RCP and they
should have
no apparent problems using it (but that of course is not what you asked
for ;)

> By the way, there exists a new open source mapping tool and runtime to
> persist
> EMF models using JDO 2.0 (JPOX also): Elver. Mapping an EMF model to an
> RDBMS is
> really nice to have when creating RCP applications. I haven't tried
> Elver though,
> but only our own brew for doing the same.

Nice. I did not know JDO2 defined ways to persist arbitrary collections
(EMF collections) efficiently,
are you sure that is not "just" JPOX features they are utilizing ?

EMF has some very intrusive design issues that makes it very hard to
persist and query completely and efficiently -
would be interested in hearing how much they have solved of that.

/max

Report message to a moderator

Previous Topic:	Where did LDT Group go?
Next Topic:	Nightly Builds

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 05:46:03 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter