Re: [jakarta.ee-spec] What are our options for Jakarta EE 10 going to ba

["reza_rahman@xxxxxxxxx" <reza_rahman@xxxxxxxxx>]

Trying to understand - Payara alone cannot pass the Jakarta EE 10 TCK and there is no other possible candidate other than GlassFish? If so I would think the most logical thing would be to see if the Concurrency updates could be contributed to GlassFish from Payara? It’s not like it’s a non-standard or closed source feature. Surely it would wind up in GlassFish sooner or later anyway?

 

---

From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Scott Marlow <smarlow@xxxxxxxxxx>
Sent: Wednesday, June 8, 2022 8:50 AM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: [jakarta.ee-spec] What are our options for Jakarta EE 10 going to ballot without GlassFish passing the Concurrency 3.0 TCK?

 

Hello,

The ongoing discussion [1][2] about GlassFish 7 implementing the remaining aspects of Concurrency 3.0 is about who will make the remaining GlassFish changes.  The Payara team is considering making the needed GlassFish changes which is great but blocking on Payara to make those changes may impact the EE 10 schedule which is a valid concern.

What are our options for going to EE 10 ballot without GlassFish passing the Concurrency 3.0 TCK but instead some other implementation passing the Concurrency 3.0 TCK?  The other implementation release would likely pass other EE 10 TCKs as well but not all of the TCKs. 

Can we go to ballot with EE 10 with GlassFish passing all of the other TCKs (not that we are there yet but are working hard on it) and the other implementation release passing the Concurrency 3.0 TCK?

Scott

[1] https://www.eclipse.org/lists/glassfish-dev/threads.html#01307
[2] https://www.eclipse.org/lists/cu-dev/threads.html#00303