On Nov 10, 2008, at 7:42 PM, Michael Dick wrote:
On Mon, Nov 10, 2008 at 6:34 PM, David Jencks
<[EMAIL PROTECTED]>wrote:
On Nov 10, 2008, at 1:13 PM, Craig L Russell wrote:
Hi Jeremy,
On Nov 10, 2008, at 12:12 PM, Jeremy Bauer wrote:
OpenJPA & Geronimo devs,
Efforts are underway to begin JPA 2.0 enhancements in OpenJPA.
OpenJPA
builds with and bundles the Geronimo JPA 1.0 spec jar. As we move
forward
to JPA 2.0, OpenJPA will need to use/provide updated spec APIs.
Like EJB
3.1, JPA 2.0 is still in the review stages so there may be frequent
updates
to the spec API until the final draft is published. This leads to
questions of "who, how, and where" for updating the JPA spec APIs
to JPA
2.0.
IMHO, it would be best if the spec jar resides in Geronimo.
+1
Even if the expert group shortly publishes a spec jar, it will not
have
the proper license.
Ideally, the
Geronimo project will have a branch for JPA 2.0 spec development,
with
the
OpenJPA project providing the JPA 2.0 enhancements. The concern
with
that
approach is that the OpenJPA committers cannot commit to the
Geronimo
repository.
Not yet, but surely this can be fixed.
OpenJPA would need committers on the Geronimo project to do
code commits and builds of the spec jar. This may become a
burden on the
Geronimo project and may be a potential (albeit small) bottleneck
for
OpenJPA development. Another alternative is for the OpenJPA
project to
temporarily update and maintain the 2.0 spec API (using the current
Geronimo
spec API as a starting point) while JPA 2.0 is in flux. Major
revisions
and/or the final could then be provided to Geronimo to be
published in
the
Geronimo repository, with the end goal of OpenJPA (and others)
using the
spec jar provided by Geronimo.
Assuming that the Geronimo PMC trusts the OpenJPA committers, one
or three
OpenJPA developers should be given commit access to the portion of
the
repository that contains the spec jar. With suitable tests to make
sure that
we don't break the Geronimo build, this should be straightforward.
Do you really expect more than 2 or three revisions before stability?
I'd suggest that we try working with patches until it turns into an
actual
problem. This might be mildly inconvenient for whoever writes the
2.0
classes but it might end up being quicker than trying to deal with
changing
svn permissions. I have no particular objection to doing this
but.... I'm
happy to apply patches quickly but have no clue what to do about svn
permissions and worry it might involve policy changes, pmc
discussions, etc
etc.
I agree. There may be a fair number of changes at the beginning but it
*should* calm down when the spec finalizes (famous last words).
When / if it becomes a problem (ie David is tired of us bothering
him :-) )
we can always fork a copy to the OpenJPA project with the intent of
merging
back when it's in less of a state of flux (or on a regular basis).
I've started off with
svn cp
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jpa_3.0_spec
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jpa_2.0_spec
and some changes to the pom so the results look like v.2. I set
the maven
version to 1.0-EA-SNAPSHOT since most of the draft specs I've seen
require
that jars clearly indicate "early access" status (I didn't check
the jpa
spec specificially).
This points out the possible problem that the jpa 1.0 spec appeared
to be
part of the ejb 3.0 spec so I gave it a spec version number of
3.0. Any
suggestions about what to do about this would be appreciated.
I think the ideal fix is to copy geronimo-jpa_3.0_spec to
geronimo-jpa_1.0_spec and announce that we're going to remove
geronimo-jpa_3.0_spec at some point in the future. There's some
precedent
for moving a maven artifact - moving ant:ant to org.apache.ant:ant
comes to
mind, so it might be permissable.
I don't know if there's a good way to properly announce it to users
(potentially a superset of say geronimo-users) , I suspect we can
learn
from what the ant team did and communicate the change in the same way.
There's some kind of relocation pom.... I don't know that it's ever
been used for anything other than changing maven 1 names to maven 2
names, like in the ant example you show.
Before doing this I'd like to have a plan for what to do in a couple
years when jpa 3.0 is proposed..... how will we avoid a collision?
the existing geronimo-jpa_3.0_spec-<version>.jar jars will still be
out there.
thanks
david jencks
Best Regards,
-mike
thanks
david jencks
Craig
Thoughts/ideas/opinions?
-Jeremy (OpenJPA committer)
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
