openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <>
Subject Re: [VOTE] Graduate from Incubation
Date Fri, 04 May 2007 20:01:51 GMT
Hi Phill,

My sense of this community is that they don't want to be restricted  
in the space of API implementations that make sense for their  
pluggable persistence engine.

I would like to hear from other community members on this subject.

If you feel that you want to change your vote and have the community  
vote on adding restrictions of their charter in the board resolution,  
please do follow up. I'm happy to call another vote on this specific  
subject prior to asking for Incubator approval to graduate. Just ask.

On May 4, 2007, at 12:16 PM, Phill Moran wrote:

> Without getting any nastier let me explain.

I don't see any evidence of nasty.

> I see a discontinuity in calling the
> project OpenJPA if in reality the project implements JDO and so forth.

The project is clearly focused now on building a solid implementation  
of the JPA API. But I don't see why we would want to require a  
different community to be formed to build a different interface.  
There are people in this community with broader interests than JPA.

And I'm also concerned that since we are trying to build a diverse  
community, we want to be as inclusive as makes sense. Narrowing the  
board charter won't help in community building.

Look at Cayenne. No one would tell them not to implement a different  
API. Their board charter is as broad as ours.

> If we can separate the engine from the API and make the API  
> pluggable/selectable
> and the project is planning on implementing other APIs then a name  
> change seems
> reasonable as it would not be representative of what we are providing.

There are good marketing reasons for calling the project Apache  
OpenJPA. But please look at the history of persistence APIs and  
projects. Which API will be dominant in 3 years? Still Hibernate? And  
what if we want to experiment with a Groovy subset/superset of JPA  
that might be more appropriate for scripting?

> If we are to go down this path then I would further suggest we  
> separate the
> engine and implementing APIS into separate jars/packages as it is  
> wasteful

Already been done. Please look at the package structure. Nothing  
wasted. And if we did ship an SDO implementation it could ship with  
its own dependencies excluding JPA or including JPA interface. We  
already publish our artifacts separately via maven in addition to  
publishing a fat jar and binary and source distributions.

> and potentially dangerous to package all implementations together.

Dangerous? Interesting theory.

> That is all this little piece of the community has to say.

I do appreciate your bringing up this issue to make sure we have  

> Phill
> -----Original Message-----
> From: Dain Sundstrom []
> Sent: May 4, 2007 2:50 PM
> To:
> Subject: Re: [VOTE] Graduate from Incubation
> On May 4, 2007, at 10:50 AM, Phill Moran wrote:
>> Would we then not have to change the overall name from JPA to
>> openPersistence or some such?
> That would suck.  I see no reason we would "have to change" the  
> name.  It is a
> choice of the community.
>> Why not let another project lift out the engine and adapt JDO/SDO/ETC
>> and maybe we remerge the projects later.
> I would hate to see a fork.
>> Maybe this idea works if we can fully separate the API from the
>> persistence engine as it does not make sense to go into production
>> with several unused API being deployed.
> It is already separated.
> -dain

Craig Russell

View raw message