|Re: [jakarta.ee-spec] [External] : Guidance on EE 10 release and the (older) Standalone Authentication TCK tests + TCKs passed for Authentication 3.0 Ballot...|
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?
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.
On 6/22/2022 12:37 PM, Scott Marlow wrote:
The Authentication 3.0 TCK test results for the Spec ballot  includes running both the old  + new  Authentication TCK tests, however, only the new Authentication TCK  were promoted to the Eclipse download site .
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  TCK so that compatible EE 10 implementations can pass that as was done for the  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  (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).
 is the tracking issue for releasing the updated Authentication TCK with the old TCK tests.
 old https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/jakarta-authentication-tck-3.0.0.zip
 new https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee10/staged/eftl/jakarta-authentication-tck-3.0.0-dist.zip
jakarta.ee-spec mailing list
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$
Back to the top