Scott,
Even if it doesn't
make sense, I think those are the rules... At least for these initial
removed features. For example, let's pretend the Open Liberty wanted
to continue to support J2EE Management after it was removed from Jakarta
EE 9. J2EE Management was originally part of Java EE and under the
javax namespace. Thus, falling under the old rules put in place by
the JCP. If an app server ships the J2EE Management API, then a corresponding
implementation which passes the TCK is required.
That's the way
that I have always understood the rules concerning Java EE. Now,
if someone can cite an alternate understanding, then I'm happy to be corrected.
Or, maybe something changed since we shipped J2EE Management with
Jakarta EE 8? I didn't think so since it still uses the javax namespace.
Maybe someone from Oracle needs to clarify the requirements?
The Java EE requirement is that if you ship an an optional API, you would have to pass the standalone TCK if it was added to the platform. It does not matter whether the platform requires it or not, The API had to be compliant to the specification that it supported. There were no exceptions to this from a Java EE perspective.
If you make technologies for example EJB optional, it gets a bit more challenging as there is no standalone TCK (unless one is created) and there is no guarantee the previous TCK would run using a newer JDK.
Best Lance (BTW, this is
another advantage of moving to the jakarta namespace. We can define
our own rules going forward for removed features post Jakarta EE 9.)
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Scott
Stark <starksm64@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
07/02/2020
09:35Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance
tests (was: Inconsistency on the term "pruned")Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
That does not make sense. Once removed
from the platform, it is a vendor specific feature. It is up to them how
they test that feature, and that can not be a requirement for certification.On Thu, Jul 2, 2020 at 9:00 AM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:Correct.
Removed features can continue to be shipped and packaged with a compliant
app server. The TCK from the past release would still need to be
executed and passed for these removed features.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Gurkan
Erdogdu <cgurkanerdogdu@xxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 07/02/2020
08:31
Subject: [EXTERNAL]
Re: [jakartaee-platform-dev] Fair rules for "optional" TCK compliance
tests (was: Inconsistency on the term "pruned")
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I
thought we did away with the restriction that removed features cannot be
shipped
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
