openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dick <>
Subject Re: [DISCUSS] JDO usage end-of-life?
Date Tue, 11 Oct 2011 02:21:20 GMT
There is at least some interest from a subset of our users. Matthew Adams
and issue: OPENJPA-1744
<>to add support for
JDO last July. I closed the issue, but Matthew responded
and the issue was reopened.

There hasn't been a lot of activity on the JIRA since then. There are some
users watching it, but no one has voted for it. If there's an outpouring of
support from the users list, and a committer (or aspiriing committer) is
interested in championing the effort, I'd be all for adding a JDO persona.
Absent a champion who is ready to dive into the code, I think that we should
clean up the references to jdo.

Even if OpenJPA removes the references to JDO, I'm sure a separate module
could be written that sits on top of our binaries. I suspect that's what BEA
/ Oracle did.


On Mon, Oct 10, 2011 at 8:18 AM, Kevin Sutter <> wrote:

> Hi,
> Sorry to cross post to both forums, but I wanted to ensure that I hit
> everybody that might have an opinion on this JDO topic...
> Is the JDO personality of OpenJPA still being utilized?  Marc's recent post
> about possibly pulling in javax.jdo.* packages during the enhancement
> processing [1] reminded me that we still have old remnants of JDO (and
> Kodo)
> in the OpenJPA code base.  OpenJPA has never claimed support for JDO (nor
> Kodo).  Way back when, BEA provided a JDO implementation as part of their
> offering that sat on top of OpenJPA.  As far as I know, BEA (and Oracle)
> only support the 1.1.x service stream of OpenJPA.  So, if we did this in
> the
> 2.x stream, there should be no effects to that set of users.
> Would there be a concern with the current users of OpenJPA to clean up the
> code base and remove these JDO/Kodo references?  From a JPA/OpenJPA
> perspective, you should see no differences in functionality.
> Like I said, Marc's posting prompted me to revisit this topic.  I'm just
> exploring the option with no immediate plans of actually doing the work...
> Thanks,
> Kevin
> [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message