Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final
Hi,

The signature maintainers did some amazing work after the fork :) 

Maybe at some point the need for all of this can be address as well? https://github.com/jakartaee/faces/tree/4.1/tck/faces-signaturetest/src/test/java/ee/jakarta/tck/faces/signaturetest

That would make it even easier to reuse the signature creating and testing between projects.

Kind regards,
Arjan Tijms

On Thu, 14 Mar 2024 at 18:21, Scott Marlow <smarlow@xxxxxxxxxx> wrote:

I think that we also need to update "excludeJdkClasses" tck/src/main/java/ee/jakarta/tck/concurrent/common/signature/SigTestDriver.java to include the same classes added by the https://github.com/jakartaee/concurrency/pull/393 change which I think will help us pass Concurrency 3.1 Signature Tests on Java 21.

We also need to update the Signature test tooling to better ignore the Java SE classes so that we don't have to spend time on changes like ^ in the future.

On 3/14/24 12:21, Arjan Tijms via cu-dev wrote:
Hi, 

Regarding the Signature tests, I recently did them for the upcoming Faces 4.1 TCK.

A signature can be generated from a given API jar using this: https://github.com/jakartaee/faces/tree/4.1/tck/faces-signaturegen

And then another jar can be tested against it with this: https://github.com/jakartaee/faces/tree/4.1/tck/faces-signaturetest

It should be relatively easy to copy that over to the Concurrency TCK and adjust the package and API names where needed.

Kind regards,
Arjan Tijms





On Thu, 14 Mar 2024 at 14:47, Nathan Rauh via cu-dev <cu-dev@xxxxxxxxxxx> wrote:

Petr,

That’s great to hear. It sounds like you are very close to having it all passing! Are you also covering Java 17, or only 21?  We will need to have passing TCK results from compatible implementations on both Java SE levels given the decision that was made at the platform level about requiring Java 17.  If not, it is an option to have different compatible implementations per Java SE level when we submit for component spec release review.

 

Regarding the signature tests, I assume we would not be allowed to not have them at all.  I’ll let Kyle comment on the signature tests because he has been more involved in them. He is out for a day or two but it is back next week.

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht via cu-dev <cu-dev@xxxxxxxxxxx>
Date: Thursday, March 14, 2024 at 8:35 AM
To: cu-dev@xxxxxxxxxxx <cu-dev@xxxxxxxxxxx>
Cc: Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final

Hello Nathan, Concurro is heading towards implementation of 3. 1. We started to execute the TCK in Payara, currently with result: Tests run: 242, Failures: 5, Errors: 4, Skipped: 24 With Ondro, we did the Flow support today (PR in Concurro). 

Hello Nathan,

Concurro is heading towards implementation of 3.1. We started to execute the TCK in Payara, currently with result:

Tests run: 242, Failures: 5, Errors: 4, Skipped: 24

With Ondro, we did the Flow support today (PR in Concurro). Some fixes were done in TCK itself, there is definitely one more error in testSignature.

The work will continue, so I think that Concurro+Payara can serve as the compatible implementation on Java 21. It will at least test the TCK. I also plan to add the required parts to Glassfish.

 

Regarding SignatureTests -- are we going to work on it? I am convinced, that we discussed its removal, but there were some changes, so it looks like we are going to adapt it to Java 21?

Petr

 

 

On 3/11/24 9:45 PM, Nathan Rauh via cu-dev wrote:

As a Jakarta EE 11 specification in wave 6, Jakarta Concurrency 3.1’s deadline for component specification release review is April 27, 2024.  It might sound like is it still a ways off, but it requires our specification to publish fully passing TCK results on Java 21 and 17 from a compatible implementation alpha, beta, or GA release with publicly available download, after having pushed a candidate final copy of the specification to staging that can be published upon successful review.

 

We need to come up with plans for what our compatible implementation is expected to be and line it up with these dates.

 

In order for Open Liberty to be a compatible implementation for certification of Jakarta Concurrency 3.1, our release process would require a 3.1 RC1 to be created by March 20th, after which the API, specification requirements (and preferably TCK) must not change.  This would allow for the creation of a downloadable beta release that will become available in time to officially pass the TCK and post results by the component specification deadline.

 

Are there any other implementations that could be candidates to use for certification of 3.1?

I noticed there has been a lot of work in the Concurro implementation.  Someone who is working on it would need to let us know how it lines up with the wave 6 component spec release review deadline. 



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

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

Back to the top