While there is a lot of discussion in the OSGi EEG about *future*
versioning policy for APIs defined outside OSGi, there was a final
decision for JPA in the OSGi 4.2 Enterprise Specification. Which is that
the JPA 2.0 API packages should be exported as version 1.1 with a 'jpa'
attribute indicating the spec version. For example:
Export-Package: javax.persistence; version=1.1; jpa=2.0
And the RI will be changed in line with this. I believe the RI may also
export the API packages at 2.0 but the spec won't require this.
- Ian
1.1 API a JPA 2.0 provider Fi for the
On 20/01/2010 21:48, David Jencks wrote:
Isn't there a lot of discussion of how to connect jsr versions to
package versions? I haven't seen any conclusions. To me it seems
obvious that if the osgi package version isn't equal to the jsr spec
version (with suitable transformations for stuff like 1.1-MR3 jsr
versions) the osgi ee effort will be practically unusable.
So, I think the geronimo jar is packaged correctly.
thanks
david jencks
On Jan 20, 2010, at 8:39 AM, Timothy Ward wrote:
Hi,
In testing I have found that the Geronimo JPA API is being exported
at the wrong version in its bundle manifest. As the JPA version 2.0
API is compatible with version 1.0, the OSGi version for those
packages should be 1.1.0, not 2.0.0.
What do people think the best solution for this is? We can either
raise a JIRA against Geronimo to get this fixed, or we can re-package
the API within Aries using the correct OSGi version.
Regards,
Tim
_________________________________________________________________
Tell us your greatest, weirdest and funniest Hotmail stories
http://clk.atdmt.com/UKM/go/195013117/direct/01/
