Hi all,
On Mon, 18 Aug 2025 at 05:36, David Blevins dblevins@xxxxxxxxxxxxx wrote:
I agree that any remaining references to EE4J should be removed. Over the past period I’ve worked on separating Jakarta EE–related specifications from EE4J and placing them directly under Jakarta EE. Examples include the Concurrency RI, JSP RI, and EL RI, which were previously coupled with implementation projects. These have since been rebranded (e.g., Concurro, WaSP, and Expressly) to emphasize that they are not more “special” than any other implementation.
The Jakarta EE tutorial has also been moved, though the examples it references still need to follow. The status of the starter project (https://github.com/eclipse-ee4j/starter) may also warrant discussion, as it arguably fits better under Jakarta EE than EE4J.
Maintaining vendor neutrality is important for Jakarta EE, and I fully support that principle.
On a related note, it would be valuable to have a complete set of Jakarta EE 11+ TCK runners for implementations such as WildFly, Liberty, and TomEE as part of the Jakarta EE TCK project. This would allow users to easily execute the TCK—or subsets of it—against any implementation for comparison and additional validation.
The GlassFish team has invested significant effort in making our TCK runners broadly available, enabling straightforward validation and serving as a reference for implementers. While we also encounter challenges, it is not always easy for us to benefit from similar guidance provided by others.
Kind regards,
Arjan Tijms