Leaving the exact name for any of that aside, I also feel this is more suitable for Jakarta EE 10 and above, because there plenty of other questions will come up about new profiles or features, e.g. (assuming MVC and NoSQL were both ready in time) "do we mandate both JPA and NoSQL or could either of them be optional?" or similar questions for GUI specs from Servlet, JSP, JSF all the way to MVC.
Werner
Thanks for raising this issue, David. This "required" Optional aspects of the Specifications will forever tie us to Glassfish. And, like you said, that's not fair to the Glassfish team or the other Compatible Implementations.
I like the idea of creating "extensions" or "standalone" specifications for the optional pieces. This would allow many alternatives for verifying the final "core" Specification instead of relying just on Glassfish. It would also allow various timelines for accomplishing the task for verifying these "extensions". That is, we wouldn't be tied to it for the "GA release" of Jakarta EE x.
Question: Would we actually consider this for Jakarta EE 9? Personally, I think we're too far down the pike to change course for 9, but this sounds like an excellent idea to kick off with Jakarta EE 10.
---------------------------------------------------
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: "Kevin Sutter" <sutter@xxxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 07/02/2020 09:01
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
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
On Thu, Jul 2, 2020 at 4:23 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
I thought we did away with the restriction that removed features cannot be shipped. I certainly made that comment on the EE 9 platform spec when that showed up. This is the crux of the problem. We need to be more aggressive at removing features and have no restriction on vendors that want to support legacy spec features.
On Wed, Jul 1, 2020 at 7:52 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> On May 22, 2020, at 1:20 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>
> Unless we fix that last bullet everything will stay in optional status and we'll create a situation that is in practice competitively unfair to GlassFish.
I'd like to start a thread which does not need to complete now, but I think would be good to get going.
In our 'Inconsistency on the term "pruned"' thread I raised the point that our current TCK rules around optional are competitively unfair to GlassFish.
The rules we have now state that one implementation must implement all optional parts of a specification before that specification and TCK go final. To understand why this is an incredible disadvantage let's talk about how optional features come into our lives and why they are so hard to remove.
It's very common that an implementation has an innovation that is very popular with their users and gains some limited traction with other implementations. That feature often finds its way into a specification as a standard requirement. Over time sometimes that idea never catches on with other user bases or loses favor to better techniques in the industry. In that situation, however, the original user base tied to the implementation that founded the idea will still be there, only now dependent on the standard interfaces.
This puts us in a catch 22.
- If we remove the feature, that means per the current rules it cannot be shipped by anyone. This damages the user base of the implementation that innovated the idea basically saying to them, "The users of other vendors didn't find the feature you critically need to be as useful as you do, so now you can't use it anymore."
- If we mark it optional, that means per current rules one implementation must implement it and all other optional ideas. This damages that implementation as they're basically in the position to have to implement everyone's failed ideas. Being the industry's technical debt collector is not competitively fair and only gets worse with time.
So what do we do?
Down one path we nuke and entire implementation and their oldest users. Down the other path we bog and implementation down with technical debt they can't reasonably pay for as they don't have the users that need it.
Neither are good options and I suggest the only fair and just solution is we find a way to shift the debt to the implementation that not only can pay it, but needs it to survive.
Here are two ways we could solve that. While not sexy, they are potentially better than the consequences above:
- Require "a sufficient number of compatible implementations" to prove all optional tests. Meaning, we may need more than one compatible implementation to be present for a specification to go final. The Pizza specification requires Cheese and has options for Pepperoni, Onions and Pinneapple. Joe's implementation has Onion and Peperoni. Jane's implementation has Pepperoni and Pineapple. Between the two of them all requirements are met and we reasonable know all parts of the TCK can be passed. Until both show up, however, the specification and TCK cannot be released.
- Split optional tests into their own spec/tck that can be implemented and released later. We see over time Willy is the only implementation shipping Pineapple and is not keeping up. We split out the Pineapple tests into its own specification/tck and it sits there till Willy is able to pass it. From the Pizza Platform perspective it is not optional or removed, it simply has reverted back to being a standalone specification with no connection to the Platform.
I suggest there is no universal decision we need to make between A or B. In some situations we may chose A, in others B. We may in fact find ourselves in the patter where we try A for a while and revert to B if we see impact on our timelines.
Thoughts?
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
_______________________________________________
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
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com_______________________________________________
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
