> 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
