I see a discontinuity in calling the project OpenJPA if in reality the project implements JDO and so forth.
I agree; there is a logical disconnection here.
If we can separate the engine from the API and make the API pluggable/selectable
The engine is very well-separated from the API as things stand now, and the API is 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.
... however, currently, the OpenJPA project only supports JPA bindings. I'd like to see other bindings for OpenJPA, but as things stand right now, things happen to line up nicely.
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 an potentially dangerous to package all implementations together.
This can actually be done today. The only distribution that the OpenJPA community has published to date is a monolithic jar, but given how the build process works today, it'd be fairly trivial to do something else. I don't think that we should change the name right now. We (the OpenJPA community) have built a name around the community, and there are currently no plans that I know of to add new APIs on top of OpenJPA. I think that we can always change the name of the underlying engine at a later time with minimal disruption. If we do decide to change the name, I'd strongly suggest that we create a TLP with some other more-flexible name, and then simultaneously create a project within that TLP called 'OpenJPA', which publishes a distribution that looks much like the current incubating releases. Then, new API bindings could be started as sub-projects within that TLP, rather than actually creating separate projects. -Patrick On 5/4/07, Phill Moran <[EMAIL PROTECTED]> wrote:
Without getting any nastier let me explain. I see a discontinuity in calling the project OpenJPA if in reality the project implements JDO and so forth. 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. 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 an potentially dangerous to package all implementations together. That is all this little piece of the community has to say. 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
-- Patrick Linskey 202 669 5907
