[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] Jakarta Transaction signatures (maybe others)
|
Thanks, Ed. From
a prioritization viewpoint, we can definitely postpone the delivery of
the Java SE 11 signature files until *after* Milestone 1 is delivered.
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/kevinwsutterFrom:
Ed
Bratt <ed.bratt@xxxxxxxxxx>To:
jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Scott Marlow
<smarlow@xxxxxxxxxx>Date:
06/11/2020
13:15Subject:
[EXTERNAL]
Re: [jakartaee-tck-dev] Jakarta Transaction signatures (maybe
others)Sent
by: jakartaee-tck-dev-bounces@xxxxxxxxxxx
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.)-- EdOn 6/11/2020 10:16 AM, Scott Marlow wrote: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/apidocsshould 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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
