| Re: [jakartaee-tck-dev] Jakarta Transaction signatures (maybe others) |
Since we won't likely have Java 11 support in the Milestone, I
wonder if we should prioritize those signatures for post MS1.
Kevin, would that be acceptable? (Of course, if TCK team can get there, great, but there are still other issues that, I think need attention.)
-- Ed
On Thu, Jun 11, 2020 at 12:35 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Scott,
> We should ensure that we have signature files for se8/se11 signature files for each Jakarta EE 9 SPEC API.
Yes, please.
> For signature files that are not used, do we need to keep those or can we delete them?
They could be deleted. Let's just ensure that they are no longer required before we delete them.
> I am wondering if it would help to have an external list somewhere of all the Jakarta EE 9 SPEC API classes, so that one could (via inspection by humans initially) validate that we have the correct signatures in the Platform TCK? If yes, I propose a simple script that generates an asciidoc/text file containing all of the said EE 9 classes, that could be merged to a central repo. This generated document could be considered the truth of exactly which classes in EE 9 applications should use the jakarta package as well. If we already have this, please mention the link, so we can reference it in future conversations. :)
Not sure what this would provide. We are already creating the Platform and Web Profile API jar files, which should represent all of the Jakarta EE 9 Spec API classes. These are created via the jakartaee-api repository:
https://github.com/eclipse-ee4j/jakartaee-api
And, the generated jar files are placed in Maven central, once they are released.
Thanks, I run this locally and think that the generated jakartaee-api/jakartaee-api/target/site/apidocs HTML output, can help answer a question that came up yesterday about why the TCK output shows a javax.security.auth.Subject class being referenced. There is a jakarta.security.auth package but that doesn't contain Subject. I thought the (Java SE) javax.security.auth.Subject reference was correct but was looking for something to link to, that backs up my understanding.
https://jakarta.ee/specifications/platform/9/apidocs should cover this need when available.
> Perhaps we could also have a script that validates that the EE 9 Platform TCK signature files do represent all of the classes identified by the external list of EE 9 classes (the script could generate that list as well, instead of reading the list from the external asciidoc file).
Isn't that the point of the TCK and CI -- to validate both the tests and the generated artifacts (APIs and/or CI)?
Maybe I'm missing the point of your question...
I had another problem in mind to catch with validation scripting, but I don't think it would catch the type of mistake I was thinking of.
Scott
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Scott Marlow <smarlow@xxxxxxxxxx>
To: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 06/11/2020 08:23
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] Jakarta Transaction signatures (maybe others)
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
On Thu, Jun 11, 2020 at 5:19 AM Tom Jenkinson <tom.jenkinson@xxxxxxxxxx> wrote:
I might have misinterpreted https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00413.html- perhaps we want both the Jakarta EE 8 and Jakarta EE 9 signatures on master? If so, we might need to keep javax.transaction.sig_1.3_se8 (if that was indeed the Jakarta EE 8 version). However, I would think that removing javax.transaction.sig_1.2_se8 at least would be consistent with that message (if it can be).
We should ensure that we have signature files for se8/se11 signature files for each Jakarta EE 9 SPEC API.
For signature files that are not used, do we need to keep those or can we delete them?
I am wondering if it would help to have an external list somewhere of all the Jakarta EE 9 SPEC API classes, so that one could (via inspection by humans initially) validate that we have the correct signatures in the Platform TCK? If yes, I propose a simple script that generates an asciidoc/text file containing all of the said EE 9 classes, that could be merged to a central repo. This generated document could be considered the truth of exactly which classes in EE 9 applications should use the jakarta package as well. If we already have this, please mention the link, so we can reference it in future conversations. :)
Perhaps we could also have a script that validates that the EE 9 Platform TCK signature files do represent all of the classes identified by the external list of EE 9 classes (the script could generate that list as well, instead of reading the list from the external asciidoc file).
Hope this helps,
Scott
On Wed, 10 Jun 2020 at 19:41, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
As a reminder, all APIs need to be at the Java SE 8 source and binary levels. The implementations need to support Java SE 11, but the APIs still need to be at the Java SE 8 level. I'm not exactly clear on how these signature files get processed for the TCK, but when I see items proposed to be deleted related to Java SE 8 and APIs, it makes me nervous... Thanks.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Tom Jenkinson <tom.jenkinson@xxxxxxxxxx>
To: Alwin Joseph <alwin.joseph@xxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date: 06/10/2020 11:44
Subject: [EXTERNAL] Re: [jakartaee-tck-dev] Jakarta Transaction signatures (maybe others)
Sent by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
I whatever you provided as [1] was not included in your message?
But Glassfish master seems to be using 2.0.0-RC2: https://github.com/eclipse-ee4j/glassfish/blob/master/appserver/pom.xml#L130. That version you can find in staging: https://jakarta.oss.sonatype.org/content/groups/staging/jakarta/transaction/jakarta.transaction-api/2.0.0-RC2/
On Wed, 10 Jun 2020 at 16:03, Alwin Joseph <alwin.joseph@xxxxxxxxxx> wrote:
Hi Tom,
As of now we have generated new signature file to be run in JDK8 as jakarta.transaction.sig_2.0_se8(using [1], Is this the same jar that is integrated to glassfish ?)
The sig tests currently pass in standalone mode, but fails in jsp & servlet vehicles, this needs to be investigated.
We will remove the javax.* and also update the jakarta.transaction.sig_1.2_se11 as jakarta.transaction.sig_2.0_se11 to be run in JDK11.
Regards,
Alwin
On 10/06/20 7:18 pm, Tom Jenkinson wrote:
Hi,
I am not very familiar with the requirements on signatures, but when I look at https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00413.htmland at https://github.com/eclipse-ee4j/jakartaee-tck/tree/master/src/com/sun/ts/tests/signaturetest/signature-repository, for Jakarta Transactions I am thinking:
1. We need to add a jakarta.transaction.sig_2.0_se11 (I am not sure what would go in there though)
2. The following should be removed:
* jakarta.transaction.sig_1.2_se11
* javax.transaction.sig_1.2_se8
* javax.transaction.sig_1.3_se8
Thanks for your assistance,
Tom
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev