openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: OSGi and javax.persistence package versions.
Date Thu, 22 Apr 2010 17:16:21 GMT
Rick, once the updated specs are released, I'll upgrade our trunk code
(2.1.0-SNAPSHOT) using OPENJPA-1637 to use the updated specs -

If all goes well after a couple weeks of testing, we can then consider
upgrading 2.0.1-SNAPSHOT to these newer levels.


On 4/9/10 1:57 PM, Donald Woods wrote:
> Rick, how about we try upgrading our trunk (2.1.0-SNAPSHOT) to use the
> new spec jar once it's published in the SNAPSHOT repo and start testing
> with it?  That way, we don't break Aries or anyone else who is picking
> up the 2.0.x code until we've had time to warn everyone about the change
> and coordinate it between projects.
> Since Aries 0.1-incubating is being staged for voting now and uses
> openjpa-2.0.0-beta3, I'd guess you'll need a 0.2 release from them that
> uses either a openjpa 2.0.1 or 2.1.0 milestone release for your Geronimo
> 3.0 milestone release later this month....
> -Donald
> On 4/9/10 1:16 PM, Kevin Sutter wrote:
>> Rick,
>> If you mean that you are asking for some changes before we cut the official
>> 2.0.0 release of OpenJPA, I don't see that happening...  This request is
>> coming in way too late.  We're planning to cut the 2.0.0 release this
>> afternoon.  We could continue this conversation and determine what, if
>> anything, needs to be done in the 2.0.x service stream.
>> On first blush, this sounds more like two separate packaging schemes.  One
>> of Java EE packaging, and one for OSGi packaging.
>> Also, it's interesting that we haven't previously heard this request from
>> the Aries team.  We've been working with that team as they have prepped for
>> their alphas and betas, and now even with the WebSphere Feature Pack alphas
>> and betas.  They are executing against both JPA 1.0 and JPA 2.0
>> functionality, and we haven't heard this type of request from that team yet.
>> So, before we make any changes, I'd like to understand how the Aries usage
>> differs from the Geronimo usage differs from the WebSphere usage.  Then,
>> maybe we can make a proper recommendation that satisfies all parties.
>> Thanks,
>> Kevin
>> On Fri, Apr 9, 2010 at 9:56 AM, Rick McGuire <> wrote:
>>> The Geronimo project is attempting to release new versions of the different
>>> java ee 6 spec jars in the very near future.  There's one last issue that we
>>> need to wrap up before these can be released, and that's the question of
>>> what version numbers need to be used for the package exports from these API
>>> jars.  Many of the spec jars are fairly easy, but unfortunately, there are
>>> some serious issues with the JPA package exports.  This is largely due to a
>>> combination of bad timing and history, but it does need to be dealt with.
>>> The newly released OSGi Enterprise specification is very explicit about the
>>> version numbers of the javax.persistence* packages.  Unfortunately, these
>>> version numbers are not the same as the java ee version numbers.  In the
>>> OSGi spec, the JPA 1.0 packages are required to use 1.0 for the version
>>> number and JPA 2.0 package versions are at the 1.1 level.  It's fairly easy
>>> to change this, but unfortunately, a lot of things break once it is done.
>>> A lot of the breakage stems from the existing version of the
>>> geronimo-jpa_2.0_spec jar that was released back in January.  In January,
>>> the OSGi specifications were still under development, so this version of the
>>> jar used a 2.0 version for the exports.  That seemed like the sensible
>>> decision at the time.  Unfortunately, the OSGi Alliance then chose a
>>> different number scheme, creating a mismatch.
>>> Currently, OpenJPA is being built with the 1.0 version of the spec jar,
>>> which means it contains imports for the 2.0 version of these packages.  The
>>> geronimo build breaks badly using the 1.0.1-SNAPSHOT version and the OpenJPA
>>> beta because of the missing package constraints.  Repackaging OpenJPA and
>>> creating bundles with "fixed" imports will work for Geronimo, but it will
>>> probably create compatibility problems with applications compiled against
>>> the non-Geronimo version of OpenJPA.
>>> I have managed to get Geronimo building with a hybrid spec jar.  This
>>> version exports these packages with both 1.1 and 2.0 versions.  This allows
>>> both OSGi spec-compliant code and legacy code to be wired up correctly.
>>>  However, I think this needs to be considered just a short-term solution.
>>>  The real fix is to get OpenJPA built using the 1.1 package versions rather
>>> than 2.0.  I'm hopeful that this can be accomplished for the first non-beta
>>> release of OpenJPA.
>>> Rick

View raw message