Re: [jakarta.ee-spec] [External] : Guidance on EE 10 release and the (ol

[Ed Bratt <ed.bratt@xxxxxxxxxx>]

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.

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. 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.

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$