Re: [DISCUSS] Support for Hibernate 7 (JPA 3.2) in TomEE 10.1.x ?

Hi everyone,

Just a quick update on this: I believe our efforts are better spent focusing on TomEE 11, especially considering Jakarta EE 11 and the ongoing work in CXF (see https://github.com/apache/cxf/pull/2473 ).

So I won’t focuson that one (for now).

Gruß

Richard


> Am 29.07.2025 um 08:02 schrieb Richard Zowalla <[email protected]>:
> 
> Hi all,
> 
> Just a quick note to move part of a Slack discussion over to the mailing list.
> 
> I'm planning to set up the JPA TCK to help identify any potential discrepancies in test results, given that our own JPA test coverage is currently quite limited.
> 
> In the meantime, we can proceed with an EE API Shade release that includes Markus’s fix for the leaking EL API, and also prepare a patch release for TomEE 10.1.x with the latest dependency updates.
> 
> Gruß
> Richard
> 
>> Am 28.07.2025 um 21:25 schrieb Richard Zowalla <[email protected]>:
>> 
>> Hi David,
>> 
>> Regarding (1):
>> 
>> I agree that the current naming might lead to confusion or misaligned user expectations if we just include JPA 3.2 :)
>> 
>> If we go with a version-based approach, something like 10.1-jpa32 could work well—it would clearly indicate the specific change we're making to the EE10 uberjar. T
>> he only consideration is whether we want to do a release with just the EL API fix [1] before introducing any JPA 3.2-related changes to the API jar.
>> 
>> Regarding (2):
>> 
>> My initial thought was to release TomEE 10.1.1 with the EL API fix and the dependency updates we've made so far (Tomcat, etc.). Following that, we could move to version 10.2, which would include the JPA 3.2 EE API shade artifact to clearly signal the change.
>> The only downside  is that this would require multiple release votes, which could be time-consuming for our volunteer contributors.
>> 
>> As for OpenJPA, development toward JPA 3.2 is currently happening on a separate branch and hasn’t been released yet. Once it becomes available, upgrading should be straightforward.
>> 
>> Gruß
>> Richard
>> 
>> [1] https://github.com/apache/tomee-jakartaee-api/commit/7c5db38d04e212a9acafcde1dd20e7f55236df66
>> 
>> 
>>> Am 28.07.2025 um 20:15 schrieb David Blevins <[email protected]>:
>>> 
>>>> On Jul 20, 2025, at 11:04 AM, Richard Zowalla <[email protected]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Just a quick update:
>>>> 
>>>> I created an API snapshot using JPA 3.2 and deployed it to repository.a.o.
>>>> Then, I updated the version on the jpa3.2 test branch and ran a full build, including the TCKs where set up: https://ci-builds.apache.org/job/Tomee/job/pull-request-manual/163/
>>>> I also added a few tests to verify compatibility with EclipseLink, OpenJPA, and Hibernate 6.
>>>> 
>>>> Everything looks good so far. How shall we proceed?
>>>> 
>>>> Maybe something like:
>>>> 
>>>> (1) Release EE API with the fix for EL by Markus
>>> 
>>> Saw this thread come in and have been thinking and can't seem to find and good approaches.  The concern is having something called Jakarta EE 10 API that has Jakarta EE 11 APIs in them.  Ideally we call that out in some way a user could notice.
>>> 
>>> I can't think of any good solutions other than to add some word to the version such as "modified" or "upgraded" or similar.  Some kind of hint that could tip off a user.
>>> 
>>>> 
>>>> (2) Do a TomEE 10.1.x release with the fixes / dev upgrades we have so far
>>> 
>>> We created a 10.1 because we changed the MicroProfile API level.  I think that was a good call and we likely want to stay consistent with that practice and do a 10.2 to reflect the changed version, skipping 10.1.  Are we upgrading our OpenJPA major version as well?
>>> 
>>>> (3) Release EE API with JPA 3.2 + TomEE 10.2.x release soon after?
>>> 
>>> This sounds like a good approach.
>>> 
>>> 
>>> -David
>> 
>> 
>