Ed,
"Eclipse GlassFish is required today
because that's how we build TCKs…"
So it's mostly required at compile time for
the TCK but it should not be needed to run any of the TCKs?
Strictly speaking Eclipse and Jakarta EE no
longer mandate a "RI" so in that sense GlassFish is not
completely irreplaceable, but it is good to have an
implementation that is independent from the other vendors'
products even if several of them are mostly open source now.
Werner
I don't know where to jump in on this thread.
Nothing in the rules says one single product must implement
all optional features. I'd like to make two points:
First, what I think the rules and specifications say:
1. If a feature is included in Jakarta EE, it must have a
TCK.
2. If a feature in the platform is specified as Optional, the
platform that certifies compatibility of that feature must
include all other Required features. (This is also true for
component specifications, just replace component-name for
platform.)
3. If there are multiple independent optional features,
nothing says one single implementation must deliver all the
separate optional features. There must be one of each, but I
believe they can be separate compatible implementations.
Second, the hard dependency Jakarta EE has on Eclipse
GlassFish:
Eclipse GlassFish is required today because that's how we
build TCKs for 25 for Specs that come from this project. Once
the working group and/or API project teams refactor how these
TCKs are built and remove the dependency on Eclipse GlassFish,
that requirement goes away. This is not a requirement of our
rules or specification. It's just a consequence of how the
Jakarta EE TCK project implements what it does.
Currently Jakarta EE benefits from Eclipse GlassFish because
it implements all features, required or optional. This was a
consequence of the previous Reference Implementation concept.
Nothing in the Jakarta EE rules forces Eclipse GlassFish to be
used this way. On the other hand, Jakarta EE is able to
provide degrees of freedom to implementers because Eclipse
GlassFish conveniently has those features. This is not a
requirement of our rules or specifications. Eclipse GlassFish
could be replaced if there were another suitable
implementation that fills its place.
-- Ed
On 7/2/2020 8:08 AM, Kevin Sutter wrote:
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?
(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/kevinwsutter
From:
Scott
Stark <starksm64@xxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
07/02/2020
09:35
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
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
IMHO, you can ship but when you ship, you need the pass
the related TCK suite
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev