Re: [jakartaee-platform-dev] [jakarta.ee-spec] What are our options for

[Jan Westerkamp <jan.westerkamp@xxxxxxx>]

I still hope there is a chance to do the release with the support of Payara.

But, as a fallback solution there might be a chance to have a CI for the Core Profile only, where Concurrency is not included, right? So we can release this, may be even with more than one CI only and release the Web and Full Profile/Platform a little bit later, when the issues are fixed.

Am 08.06.22 um 17:08 schrieb Scott Stark:

Right, they would have to ask their favorite project when they will be fully certified. Effectively there would need to be a ratification type of CCR that did not convey full compliance, but that is what reflects the reality of doing away with a single reference implementation in favor of multiple compatible implementation. The downside being what you have referred to.

On Jun 8, 2022 at 10:00:26 AM, reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx> wrote:

Honestly this would be OK in practice. The only downside is that developers would be a bit confused about the fact that while there is a platform or profile release, there wouldn’t actually be anything that implements the platform or profile just yet.

 

---

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Scott Stark <starksm64@xxxxxxxxx>
Sent: Wednesday, June 8, 2022 10:13 AM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [jakarta.ee-spec] What are our options for Jakarta EE 10 going to ballot without GlassFish passing the Concurrency 3.0 TCK?

 

The main issue here is what is required for the platform spec and profiles in terms of the ratifying CCRs. We have standalone TCKs being ratified that are not using GlassFish. It would greatly simplify producing the EE releases if profiles/platform specs could be ratified via a union of incomplete CCRs.

A single CCR that lists the compatible implementation for the profile/platform in question, and then the compatible implementation for each standalone TCK is what would be ideal. If we could to that, we would have a CCR today.

I'm CCing the platform team as is probably also is up to them as to what they would be willing to accept.

On Jun 8, 2022 at 7:50:30 AM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:

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

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev