> On May 2, 2021, at 10:22 AM, Alex The Rocker <[email protected]> wrote: > > Hi David, > > Thanks for your answer, this is perfectly clear. > > Will this upcoming TomEE 8.0.7 release include latest Tomcat / CXF > dependencies that fixes CVEs that showed up since 8.0.6 release ?
It'll definitely contain the latest CXF as many of the TCK failures were there. We're actually building against the unreleased 3.5.0-SNAPSHOT, but hopefully we can back that down to the last release, 3.4.3. I don't know the status of the Tomcat version as I've not been doing those TCK fixes, but I suspect it's the latest latest. If anything is missed, we can roll a 8.0.8 immediately even as soon as Tuesday. Basically, if we don't get a release vote up in the 8 to 16 hours, we'll miss the Jakarta EE 9.1 release window. -David > > Le dim. 2 mai 2021 à 19:09, David Blevins <[email protected]> a écrit : >> >>> On May 2, 2021, at 9:39 AM, Alex The Rocker <[email protected]> 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 <[email protected]> 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 >>>> >>
