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
