Hello David, Thank you very much for this "insider's" view, this is very clear.
It that helps, I can guarantee that people working with me and relying on TomEE are absolutly not obsessed by strict Java EE / Jakarta EE compliance. Stability on the "core features" is what matters most. Of course. having a reasonably evolving application server in term of features so as to keep up with potential new needs is also "nice to have" (more than "nice to have" when it comes to support updated dependencies such as recent Java runtime LTS versions), but again stability (including getting quickly fixes for CVEs) is what matters most to us. That said, what you propose about being part of Jakarta EE 12 on-going specifications can also be a motivating drivers for TomEE contributors. By doing so, they will feel the power of being part of decisions, rather than fighting hard at trying to comply with past choices (which may not be adapted to TomEE's architecture). Again thank you very for all inspiring thoughts ! Alex Le jeu. 24 oct. 2024 à 23:53, David Blevins <david.blev...@gmail.com> a écrit : > > > > > On Oct 17, 2024, at 1:47 AM, Richard Zowalla <r...@apache.org> wrote: > > > > Hi all, > > > > We are receiving more and more queries regarding the EOL Tomcat in TomEE > > 9.1.x - it is cumbersome to explain the same thing over and over again. > > Given that we are on limited capacity and work on EE10 is mostly dependent > > on the GA of CXF 4.1.x (which might take some more time until it is finally > > available), I would like to discuss the > > Roadmap towards TomEE 10 GA > > > > Situation: > > - We still haven’t set up the platform TCK for EE10. > > - We pass a few of the standalone tcks like jaxrs, concurrency, ... > > - We don’t have the full MP 6 spec implemented yet (for OpenTelemetry, we > > are waiting for a fix in OWB) but pass most of the TCK > > - Our own unit tests, integration tests, examples and arquillian tests are > > green. > > - We are waiting for a CXF 4.1 GA release > > - We depend on a M2 release of the EE 10 API > > - We depend on a M release of Geronimo Mail > > > > Proposal: > > > > I would like to propose / discuss to release TomEE 10 as GA after the > > following bullet points are resolved: > > > > - Release EE 10 API as GA. > > - Release / Work on a fix for Geronimo Mail, so it gets GA. > > - CXF 4.1 GA > > > > In a perfect world, we would set-up the platform TCK, MP6 compliance, etc. > > before going GA, but I don’t think, that this will happen in a definite > > time span because of our resource lack. > > We are already one EE version behind and given that Tomcat 11 is already > > out, we should think about our plans for EE11. But that can only happen, if > > we have a more or less stable version of TomEE 10. > > I would also support this proposal. If someone has the energy to run the > signature tests on our EE 10 API jar that would be great. That would at > least give us the confidence at least our API jars are not missing anything > or incorrect in some way. That might be something we could setup in the > build that produces the uber jar. I know there was talk on the Jakarta side > about getting that wrapped as a maven plugin. Not sure if that was done. > The actual code that's being used to do the checking lives in Apache Netbeans. > > In terms of certification, my observation of the last several years that: > > - Many people don't seem to care > - Timing impacts how easy or hard certification can be > > On the first point, TomEE 8 was never certified and people didn't seem to > care. Tomcat is not certified and people don't seem to care. TomEE 9 was > certified and I didn't notice a difference other than we all killed ourselves > doing it. Certainly it didn't bring any resources -- users don't bring > resources to the project so "more users means more support" is not a thing > that pans out in practice. > > On the second point, if you're the implementation being used as the reference > implementation (that term is technically dead, but still being done in > practice) then the bar is low. There is no challenge process, you can > straight up change the tests you can't pass -- it's done very actively. The > Jakarta EE spec committee is actually even talking about excluding valid > tests from the Jakarta EE 11 TCK because the reference implementation can't > yet pass them and they really want to get the release out this year. If you > come after the release and try to certify, good luck. Instead of being able > to change the tests to suit your needs, you have to go through a challenge > process and battle egos tirelessly for weeks or months. As well no one would > entertain and actively discuss getting tests excluded for you to meet a > deadline. Then the reality that we are often the only implementation that > doesn't ship the Eclipse implementations, so we need to file more challenges > than others. > > The short version of the above is when you're there during the spec > development the rules flow like water around you. If you show up after, the > rules are a rock you must climb over or move. If you want to move it (file a > test challenge) there are groups of people who don't want it moved because > they're very happy with where it is -- so you need to move the rock and them. > > I don't think it makes sense to play the certification game as we've been > playing it. We're always starting from a losing position. > > The only winning position is being there at the start of a major spec cycle > and then you have 2 years to do it, can do it comfortably, and have the tests > and timelines built around you, and be certified on the day of the spec > release. You can also add spec features, which is way more fun. > > If we wanted to try that Jakarta EE 12 would be the earliest opportunity. So > not only would I lean to not certify 10, but likely 11 as well and we could > potentially consider going straight to 12 which as of today isn't started. > It will be started soon though. We would probably want another thread if > this was something people would want to discuss, but ... +1 for the proposal. > > > -David >
