> On May 2, 2021, at 9:39 AM, Alex The Rocker <alex.m3...@gmail.com> wrote: > > I am a bit confused : I thought that renaming of javax.* into > jakarta.* packages for the EE API is only targeted for TomEE 9.x.
All the source code is in TomEE 8.0 and TomEE 9.0.x is just created through bytecode transformation. The long and short of that is they pass/fail almost the exact same tests as it's the same code. We can do library upgrades in the `tomee-jakarta` repo and add a patch file for third-party dependencies here and there, but any fixes on the TomEE side go into 8 and are automatically picked up in via bytecode transformation of 9 as well. In fact, I've been doing most my local work exclusively running the Jakarta EE 8 TCK and just letting the automated systems do the running of the EE 9 TCK. > In such case, what would be the content of a TomEE 8.0.7 release? Everything in this list is fixed, except about 10 tests which are not part of the Web Profile and therefore not required for certification and will be fixed later. Though it says "EE 9" these failed for both 8 and 9 TCKs: - https://issues.apache.org/jira/browse/TOMEE-3140 We're still one TCK test shy of passing and have some work to do on the API jars to pass the signature tests, but it's looking good. Brief pause for me to take a nap, however, as I've been up for 24 hours and keep nodding off at the keyboard :) -David > > In any cases, I'd be happy to see a TomEE 8.0.7 release soon, in order > to get latest CVE fixes since 8.0.6. > > Kind regards, > Alexandre > > Le sam. 1 mai 2021 à 03:32, David Blevins <david.blev...@gmail.com> a écrit : >> >> Heads up that we are narrowing in in the last few TCK issues and there is >> still some chance we can be Jakarta EE 9.1 Web Profile certified in time for >> the Jakarta EE 9.1 release vote Monday. >> >> It would be super super and I mean *super* tight.... >> >> However, if we can get it done we'll need to do a release vote by no later >> than Sunday afternoon and file our certification request. We don't need to >> have concluded our vote to make the Jakarta EE 9.1 release ballot, we just >> need final binaries of our own to be at least in staging and in the process >> of our own vote. >> >> We do need that vote pass, however, so that would require some pragmatism on >> all our parts. >> >> For that reason I recommend we do not try to push out a 9.0.0 final, but go >> ahead with 9.0.0-M7. If there are some issues with the binaries we put up >> for vote, unless they are legal issues, we can still release them and >> immediately fix the issues next week in a subsequent 8.0.8 and 9.0.0-M8. >> There's no reason to "wait", we can simply release twice. Version numbers >> are free. >> >> The Jakarta EE 9.1 release vote lasts for two weeks and an announcement >> would happen some days after that. Ff we did want to push out a 9.0.0 for >> the announcement, we'd have at least till May 17th to do that, perhaps even >> the 20th. >> >> The reason we want to get certified in time for the ballot is recently there >> was a change that implementations listed on the ballot get a special place >> at the top of the specification page. Any implementations that come even >> one day later cannot be included and will not be accepted or given special >> designation. This lasts forever and is a permanent advantage to those in >> the list. It's also a permanent *disadvantage* to those not on the list. >> It's eat or be eaten. >> >> So that's what we're going for: A staged binary up for a vote here, passing >> the TCK, in time to be listed on the Jakarta EE 9.1 release ballot Monday. >> >> >> -David >>
