[GitHub] [tomee-site-generator] cesarhernandezgt merged pull request #22: TOMEE-3733 Jakarta EE TCK summary page
cesarhernandezgt merged pull request #22: URL: https://github.com/apache/tomee-site-generator/pull/22 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Hi Alexandre, in 8.0.7, Tomcat is @ version 9.0.45 atm (TOMEE-2998). We also updated the related web.xml files for mime type mapping (TOMEE- 3718). Gruss Richard Am Sonntag, den 02.05.2021, 19:22 +0200 schrieb Alex The Rocker: > 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 ? > > Kind regards, > Alexandre > > Le dim. 2 mai 2021 à 19:09, David Blevins a > écrit : > > > On May 2, 2021, at 9:39 AM, Alex The Rocker > > > 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 > > > > -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar) mail: richard.zowa...@hs-heilbronn.de web: https://www.mi.hs-heilbronn.de/ smime.p7s Description: S/MIME cryptographic signature
Re: Potential release vote for 8.0.7 and 9.0.0-M7
Okay great for TomEE, but take some rest : it won't help if you get a burn out trying not to sleep for too long! Le dim. 2 mai 2021 à 19:32, David Blevins a écrit : > > > On May 2, 2021, at 10:22 AM, Alex The Rocker 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 a écrit : > >> > >>> On May 2, 2021, at 9:39 AM, Alex The Rocker 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 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
Re: Potential release vote for 8.0.7 and 9.0.0-M7
> On May 2, 2021, at 10:22 AM, Alex The Rocker 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 a écrit : >> >>> On May 2, 2021, at 9:39 AM, Alex The Rocker 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 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 >>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
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 ? Kind regards, Alexandre Le dim. 2 mai 2021 à 19:09, David Blevins a écrit : > > > On May 2, 2021, at 9:39 AM, Alex The Rocker 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 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 > >> >
Re: Potential release vote for 8.0.7 and 9.0.0-M7
> On May 2, 2021, at 9:39 AM, Alex The Rocker 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 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 >>
Re: Potential release vote for 8.0.7 and 9.0.0-M7
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. In such case, what would be the content of a TomEE 8.0.7 release? 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 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 >
