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
- OSGi and javax.persistence package versions. Rick McGuire
-
