openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phill Moran" <>
Subject RE: [VOTE] Graduate from Incubation
Date Fri, 04 May 2007 20:11:55 GMT
I have no desire in calling a new vote my comments where, to some degree,
philosophical. I am well along the road in implementing a application using
OpenJPA so I think we are ready to graduate.
As mentioned we currently have no plans (or restrictions for that matter) on
other APIs so keeping the name is fine. I think if we become a persistence
platform then we should serious consider a renaming in order to provide easier
understanding and discovery

Thanks again


-----Original Message-----
From: Craig L Russell [] 
Sent: May 4, 2007 4:02 PM
Subject: Re: [VOTE] Graduate from Incubation

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

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

> 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