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 >> >> >
