[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec] [External] : Guidance on EE 10 release and the (older) Standalone Authentication TCK tests + TCKs passed for Authentication 3.0 Ballot...
|
On 6/22/22 8:56 PM, Ed Bratt wrote:
As was
related in the TCK meeting this morning, the CCR for
Authentication 3.0 used two TCK files to verify compatibility
results. However, only one TCK was listed in the information
section. Both TCKs do appear to be indicated in the Spec. PR and
one appears to reference the other. Only one TCK was uploaded to
the Specification download folder.
I would like this not to be cause to invalidate our Release Ballot
for Authentication 3.0 though there might be a case for that.
I believe that both TCKs are final artifacts and must be released.
If that is accepted, we must publish both TCKs as existed for the
ballot, to align with the material that was used to certify the
initial CI in support of the Authentication project. The content
for the original CCR and the Specification Page must be updated to
reflect the second TCK.
Scott Marlow also notes that the test source in the Platform TCK
has been removed from the jakartaee-tck repository and is
suggesting this action be reverted (to allow for test challenges
if they occur against the TCK as it was released). At least until
a revised Authentication TCK ZIP is created and the sources are
properly squared away in the Authentication TCK repository.
Are there any Specification Committee interests involved with the
properly squaring away of sources being maintained for what we
balloted via Authentication 3.0? Or is is strictly a Platform
level concern where the Authentication 3.0 (old) TCK source is
maintained? I'm asking so that I can outline the options for
where the source is maintained in the appropriate mailing list.
If the Authentication team can produce another TCK that combines
the contents of both these TCKs, I am not opposed to that.
However, my recommendation for the current CCR certification of
GlassFish Platform and Web Profile -- since we are already behind
on our release time-line -- is that we simply re-run the two TCKs
as were used for the Authentication Release Review ballot and use
those results for the Platform and Web Profile CCR. This should
allow us to proceed without the need to build another
Authorization TCK -- test and verify it with a CI -- and push it
to the Platform specification pages.
I'm not really sure of when the Authentication team will release
support for running the Authentication 3.0 (old + new) TCKs as one
TCK, other than we discussed during the last Platform call, that
they would do it after the EE 10 Platform ballot starts.
If the
team wishes to hurry this up and use the new TCK, I guess that's
okay but it seems like work that could be deferred at this point.
Are there any Specification Committee concerns with completing
the combining of old + new Authentication 3.0 TCKs via a service
release that comes out after the EE 10 Platform ballot starts?
Scott
I am not sure if the Specification Release job will properly
handle more than one TCK per release version. As it is now, the
two TCKs differ only in the tail-end of their file-name and I
think the Jenkins job renames the source TCK using rules based on
the specification name and version number.
I vote for minimum effort but I don't think that needs to be
hard-and-fast. We do need to figure out how to rectify the
multiple TCK issue and publish both -- and decide if we will allow
the ballot to stand while the initial CCR is updated
retroactively. Since TCKs both were used and this is just
clarification of what was done, I am not opposed to this update.
-- Ed
On 6/22/2022 12:37 PM, Scott Marlow wrote:
The Authentication 3.0 TCK test results
for the Spec ballot [1] includes running both the old [2] + new
[3] Authentication TCK tests, however, only the new
Authentication TCK [3] were promoted to the Eclipse download
site [4].
Since our current state is post-ballot for Authentication 3.0
ballot and pre-ballot for EE 10 Platform, the minimum effort is
to release the already staged [2] TCK so that compatible EE 10
implementations can pass that as was done for the [1] ballot.
From the Platform perspective as discussed during June 21 call,
after the EE 10 ballot starts, the Authentication 3.0 Spec
project will produce a jakarta-authentication-tck-3.0.1.zip
release that includes the missing [2] (old Authentication) TCK
tests for EE implementations to run but is that allowed? Simpler
approach could be that whatever was already done for the
Authentication 3.0 Spec Ballot, the same should be done for the
EE 10 Platform (e.g. bring Authentication TCK tests back into
Platform TCK repo but only for running old Standalone
Authentication TCK by all EE 10 implementations).
[6] is the tracking issue for releasing the updated
Authentication TCK with the old TCK tests.
Scott
[1] https://github.com/jakartaee/specifications/pull/460
[2] old
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/jakarta-authentication-tck-3.0.0.zip
[3] new
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/jakarta-authentication-tck-3.0.0-dist.zip
[4]
https://download.eclipse.org/jakartaee/authentication/3.0/jakarta-authentication-tck-3.0.0.zip
[5]
https://download.eclipse.org/jakartaee/authentication/3.0/jakarta-authentication-tck-3.0.1.zip
[6] https://github.com/jakartaee/authentication/issues/166
_______________________________________________
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!ONyka4Jw-ZdUYZECPGKDbQqdlxz_wvD4XDnp4K6DTBU_zu6ZSEEeM4a37veuXKUK_on7TWEi69nygy0$