OSGi and javax.persistence package versions.

[Rick McGuire <ri...@gmail.com>]

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

Re: OSGi and javax.persistence package versions.

[Donald Woods <dw...@apache.org>]

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 -
    geronimo-jpa_2.0_spec-1.1
    geronimo-validation_1.0_spec-1.1

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


-Donald


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 <ri...@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
>>>
>>
> 

Re: OSGi and javax.persistence package versions.

[Donald Woods <dw...@apache.org>]

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 <ri...@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
>>
> 

Re: OSGi and javax.persistence package versions.

[Kevin Sutter <kw...@gmail.com>]

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 <ri...@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
>