| Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] What are our optionsfor Jakarta EE 10 going to ballot without GlassFish passing the Concurrency3.0 TCK? |
My concern is, we don't know if there is something conflicting
within the specification requirements. As the respective component
specifications are moved out of the Platform TCK project, this
project will cover less and less of the component technologies.
This problem will continue to grow.
The requirement that a product meet all the requirements listed
in that specification ensures that at least one product is able to
meet all the specifications. I know that vendors have from time to
time used that knowledge to validate their implementations.
Personally, I think that goal this is more important to the
specification on the whole, than a particular date. I would
recommend we wait until we can sort out the issue with concurrency
(I believe there are a few other straggling issues as well but
Currency seems to be the focus of this thread).
Enterprise Java has always been a tight collaboration between
implementation teams and specification writers. I think that is
one of it's key values and has set it apart from many other,
similar efforts.
-- Ed
I think it's important to bear in mind there are plenty of successful open standards/specifications that do not have any guaranteed implementations at all when they ship.
It's fine to be pragmatic, relax the rules a bit at least temporarily and see how it all plays out. I believe the most important thing is to get some kind of regular innovation cadence for Jakarta EE. There seems to be plenty of good, solid stuff in the release.
On 6/8/22 11:59 AM, Scott Stark wrote:
Yes, eventually there will be fully compliant implementations. The question is when? There is no one vendor whose produce roadmap is aligned with Jakarta EE because it is a front running development that they have to catch up too. A pseudo de facto standard is requiring other to commit resources to try to finalize the specification. This is really not a viable model given the current structure of the project.The current situation is either use a composite CCR that validates no single implementation, but provides some validation of the specification, or wait for an implementation to provide a CCR. The problem with the later is that we are currently requiring at least one implementation to pass everything TCK including optional aspects. We need to stop pushing the rock up the hill and move to a more flexible development model.
On Jun 8, 2022 at 10:48:51 AM, Werner Keil <werner.keil@xxxxxxx> wrote:
There may be a „de facto RI“ but there is no real RI anymore, so do other implementations like Wildfly, Payara or TomEE expect to pass all these TCKs in the near future?
If so then that’s fine.
Werner
Von: Steve Millidge (Payara)
Gesendet: Mittwoch, 8. Juni 2022 17:41
An: Jakarta specification discussions; jakartaee-platform developer discussions
Betreff: Re: [jakartaee-platform-dev] [jakarta.ee-spec] What are our optionsfor Jakarta EE 10 going to ballot without GlassFish passing the Concurrency3.0 TCK?
This makes sense to me as we are all effectively working towards getting our implementations compatible.
Currently we have had a de-facto RI since the beginning with GlassFish. Whereby GlassFish is required to pass all the TCKs in order to release a platform specification. This leads GlassFish to be always on the critical path for a platform release.
Having the totality of the TCK testing covered by a range of compatible implementations will also remove the requirement to have a single Compatible Implementation project team on the critical path for the platform release.
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 08 June 2022 16:08
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] [jakartaee-platform-dev] What are our options for Jakarta EE 10 going to ballot without GlassFish passing the Concurrency 3.0 TCK?
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
_______________________________________________
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
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxx To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!M-TIP-74zB67D0ap5ODbCw77SXuu2_z94exyXsZcLmQexYAN5XqQgGaLlQdLHTiM6ErkB-r6zRQP1zLHTNM$