I agree with you on the name change and the timing around it. My comments are
mainly directed towards holding a non-representative name if other APIs are
implemented.
A decision that can be made later along with any necessary re-packaging needs
Sincerely,
Phill
-----Original Message-----
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: May 4, 2007 3:35 PM
To: open-jpa-dev@incubator.apache.org
Subject: Re: [VOTE] Graduate from Incubation
> 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
