[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [ejb-dev] [External] : Please giveyour estimate of when you will complete your tasks for Jakarta EE 9.1 TCKs...
|
A couple of points -- I hope these clarify --
1) there is no stand-alone TCK for Jakarta Enterprise Beans. If
Enterprise Beans TCK changes, the Jakarta EE Platform TCK (a.k.a. CTS)
is updated and a new version is required. This is true for any Spec.
that doesn't have a stand-alone TCK (Platform, Web Profile, Enterprise
Beans, Enterprise Web Services, Interceptors, Managed Beans, Web
Services Metadata).
2) if a TCK released in 9.0 passes both JDK 11 and JDK 8 without change,
it doesn't need to be re-released but a compatible implementation must
submit a compatibility certification issue showing JDK 11.
3) Any TCK that must be rebuilt, even if there wasn't believed to be a
required change must be released again -- if for no other reason, the
SHA sums will no longer match.
(Clarifying 2 above) Since there was no Compatible Implementation
requirement for component implementations to pass JDK 11 with the 9.0
release, all specifications must verify their TCK against a compatible
implementation before we can claim those components meet the requirement
of working on JDK11. So, at the least, Compatible Implementation issues
for each spec. will be needed -- even if the TCK isn't updated.
One more reminder, compatible products must add Jakarta XML Binding TCK
results for platforms, when certifying with JDK 11 or higher (along with
their results for DI, CDI and Bean Validation).
-- Ed
On 3/19/2021 10:59 AM, David Blevins wrote:
On Mar 19, 2021, at 10:33 AM, Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
On 3/19/21, 6:22 PM, "jakartaee-platform-dev on behalf of David Blevins" <jakartaee-platform-dev-bounces@xxxxxxxxxxx on behalf of dblevins@xxxxxxxxxxxxx> wrote:
On Mar 19, 2021, at 9:26 AM, Werner Keil <werner.keil@xxxxxxx> wrote:
but David first said just release the 9.0 content unchanged with a new number and then mentioned spec XYZ indeed requires new Tests.
You interpreted that differently than what I intended to communicate.
If a scenario existed where there was no TCK changes a pragmatic way to handle that would be to simply upload the TCK again with an updated file version. The statement was intended to get ahead of complaints about extra "work" in scenarios were it could be avoided.
this solution may introduce a version number mismatch between the file name and included User Guide in some cases, may not be a big deal but anyway... Also not sure if TCK itself is printing out its exact version somewhere, that could be another source of confusion going forward
Valid concern. I wouldn't actually recommend people just upload the same binary with a different version, I'd personally prefer to do an actual release. But if we were in a situation where a spec team was resisting due to the work involved, the "upload it again" technique would be the compromise I'd offer.
-David
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!GqivPVa7Brio!OCrZkkwqF9Yb3cS_NF92WnlC5x97KY353QbvK4ePUcIdsjA5oPEXmen2-v0YbN4$
