openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [VOTE] Graduate from Incubation
Date Fri, 04 May 2007 20:10:06 GMT

On May 4, 2007, at 1:01 PM, Craig L Russell wrote:

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

Agreed wholeheartedly.

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

If anyone has a great name that sounds less restrictive than openjpa  
I'd like to hear it.  Otherwise I'd prefer to try to graduate and  
deal with the naming problem when we have another api implemented.

Personally despite the mismatch I don't have a big problem with e.g.  
openJPA implementing JDO etc.

david jencks

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