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 Fri, 09 Apr 2010 17:57:50 GMT
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....


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