| 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 Thu, Jun 23, 2022 at 2:57 AM Ed Bratt <ed.bratt@xxxxxxxxxx> 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.
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.
The current job setup does not allow for multiple files to be published with the same run, but it is possible to run the job twice with different file names. It does not alter the actual file name, it just copies it to the correct location.
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.
Yes, I agree.The PR lists both files, so it should be ok to publish the second file as well since it was a part of the material submitted for the ballot.I was the mentor for this specification, and I remember I was a little unsure when I saw two files and picked the one that said it contained both. My mistake. I should have asked, or published both at the time.
If you are all ok with the approach, I will go ahead and make sure both files are published and linked to from the Jakarta Authentication 3.0 Specification page.
+1 for publishing both files and linking to them from the Jakarta Authentication 3.0 Specification page!
Thanks Ivar!
Scott
Ivar
-- 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$
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec