Richard, Thanks for the feedback. Yes, that helps. I had been following most of that TomEE decision making, but certainly the kicker is when the dependencies start to reach end of life. Perfectly understandable that TomEE would no longer publicly support a version with known vulnerabilities and no plans for recourse.
Privately, I have devised a process to overlay new Tomcat 9 releases overtop TomEE 8 in order to deploy my server updates faster than the TomEE release cadence. So that should continue to serve me well past end of life. My gap is with those additional TomEE dependent libraries which I haven't been following as closely. Good to know that new releases are not impossible, even if advertised as unsupported. Thanks, Eric -----Original Message----- From: Richard Zowalla <rich...@zowalla.com> Sent: Thursday, October 12, 2023 3:50 PM To: dev@tomee.apache.org Subject: EXT :Re: TomEE/Tomcat Roadmap Planning Hi Eric, your assessment is correct. Currently, we are backporting security updates from TomEE 10.1.x to 10.0.x within the TomEE build. If we decide to break TCK 9.1 compliance, we could also use Tomcat 10.1.x as a basis for TomEE 9.x Regarding the bottom line: Ecosystem is moving fast (since SpringBoot pushed towards J17 + jakarta.*) and our dependencies are also steadily adapting to that pace. Even security fixes / updates are starting to come in slowly for some dependencies. In the end, it is just a matter of resources which branch gets the available time of the available contributors. Maintaining two different versions (8.x, 9.x) and working on a EE10 compliant app server on the 10.x line (with all of its 3rd party components) just exceeds the available resources / man power of this project (at least for the moment). Currently, most folks are focused on implementing the specs needed for EE10 in the related 3rd party projects and some of them already declared little interest in maintaining older versions such as 8.x [1]. The eol declation on our website says [2], that relases are unlikely but not impossible. In [1], we also discussed, that an declared end-of- life date can be extended if someone shows up willing to do the work and commits to a new end-of-life date (which can again be extended if there are volunteers). However, there is consent to not release a TomEE if transient end-of-life dependencies contain CVEs. It is unfortunate, that the Tomcat PMC declared the EE9.1 series (10.0.x) as end-of-life, IMHO, as it places a burden to check and backport CVE related fixes to TomEE 9.x until a TomEE 10.x becomes available. That being said, I also recommend to give [3] a read. Hope it helps Richard [1] https://lists.apache.org/thread/jz4y20q039cckcv436xvtgzr1ofmostj [2] https://tomee.apache.org/tomee-8.0-eol.html [3] https://lists.apache.org/thread/0zfk1xw60t9gnt69kqkh2co7yvjkrk2t Am Donnerstag, dem 12.10.2023 um 19:11 +0000 schrieb Hamilton, Eric J [US] (DS): > For planning purposes, I am trying to decipher the TomEE roadmap, and > how it aligns to supported Tomcat versions. Not sure if the > following is accurate, so please correct me if needed. > > TomEE 8.0.x - Planned End of Life Dec 31, 2023 > Based on Tomcat 9.0.x (Java EE 8) - No announced End > of Life date > > TomEE 9.1.x - No announced End of Life date > Based on Tomcat 10.0.x (Jakarta EE 9) - Already End > of Life > > TomEE 10.0.x - Under Development > Assume will be based on Tomcat 10.1.x (Jakarta EE 10) > - No announced End of Life date > > Bottom line, until a newer TomEE release is available based on a > fully supported Tomcat version for stakeholders to migrate towards, > shouldn't the TomEE 8 version continue to receive at least Tomcat 9 > and security updates? I understand if other code changes, outside of > security patches, are subject to the availability of the TomEE > volunteers. > > Thanks, > Eric >
