geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Updating the JPA spec jar for JPA 2.0
Date Tue, 11 Nov 2008 08:11:29 GMT

On Nov 10, 2008, at 7:42 PM, Michael Dick wrote:

> On Mon, Nov 10, 2008 at 6:34 PM, David Jencks  
> <david_jencks@yahoo.com>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:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>


Mime
View raw message