openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Re: OSGi and javax.persistence package versions.
Date Fri, 09 Apr 2010 17:16:44 GMT
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 <rickmcg@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message