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

Craig

Phill

-----Original Message-----
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: May 4, 2007 2:50 PM
To: open-jpa-dev@incubator.apache.org
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
DB PMC, OpenJPA PPMC
[EMAIL PROTECTED] http://db.apache.org/jdo


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to