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
Hello All,

Sorry I was out last week and am just now getting caught up on this. 

Petr, what failure are you getting from the signature test for concurrency?
Is it that the signature test is not correctly finding the concurrency API on your classpath? Or is it failing due to insufficient ignoring of JDK classes?

If you could open an issue with more details I will be happy to address it prior to the RC1 release.

Thank you,
Kyle Jon Aure

On Thu, Mar 14, 2024 at 3:54 PM Scott Marlow via cu-dev <cu-dev@xxxxxxxxxxx> wrote:


On 3/14/24 16:37, Scott Stark via cu-dev wrote:
For CDI and Validation we setup a maven project just to set the classpath for the type of signature dependencies we want to validate. For example, just the dependent CDI API jars:

For the jars that Weld depends on:

I did not look into how the SigTestDriver class actually does the testing. Is this using the netbeans sigtest code or the jakarta tck tools fork, or something else?

It was using netbeans sigtest before but looks like Faces 4.1 is using jakarta tck tools fork as per https://github.com/jakartaee/faces/blob/4.1/tck/faces-signaturetest/pom.xml#L55



On Thu, Mar 14, 2024 at 2:31 PM James Perkins <jperkins@xxxxxxxxxx> wrote:
It's possible, but we'd need to change how the class path is resolved. It shouldn't really resolve from Maven Projects class path, the class path should be required to be provided and point to server dependencies. Another idea might be to provide an abstract Arquillian test which can check that a deployments class path is setup correctly.

On Thu, Mar 14, 2024 at 12:40 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
Can this just be rolled into a run mode of the tck tools sigtest maven plugin?


On Thu, Mar 14, 2024 at 12:32 PM James Perkins via cu-dev <cu-dev@xxxxxxxxxxx> wrote:


On Thu, Mar 14, 2024 at 11:02 AM Arjan Tijms via cu-dev <cu-dev@xxxxxxxxxxx> wrote:
Hi,

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


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

I don't want to distract from the main point of this conversation too much, but I just want to add a +1 to that. I know other projects would benefit from that as well.
 

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
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev


--
James R. Perkins
JBoss by Red Hat

_______________________________________________
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