| Re: [jakartaee-platform-dev] Fair rules for"optional"TCKcompliancetests |
Guess Ed can probably help more with insight into how realistic that is Building the TCK without Glassfish in Jakarta EE 9 instead of 10 and what resources Oracle has, not to Mention the tragic loss of Bill Shannon who was one of the most profound experts in many of these aspects…? It should be a lot easier to build the TCK with say Payara due to their close relation, but do you see a realistic opportunity the TCK should be buildable without Glassfish based on Wildfly or TomEE within the Jakarta EE 9 timeframe? If it wasn’t for some JCP restrictions we could have made the JSR 385 TCK https://github.com/unitsofmeasurement/unit-tck as flexible as to say implementation A just supports Length, while B can only support Mass or Temperature. We made a compromise there with SI Base Quantities and "All Quantities" but the TCK could have been created with a "Mix & Match" profile allowing to pick just a number of types. I know CDI and probably Bean Validation should have TCKs that are equally flexible because we borrowed from them in 385, but hard to say, if the entire platform TCK was able to gain a similar flexibility or independence from Glassfish in this release? Werner From: Scott Stark The fundamental problem is that too many assumptions around the existence of "de facto RI" as you stated, exist. As I said, Jakarta EE8 was not a real test of the Jakarta process. Jakarta EE 9 is, and there are clearly issues relating to infrastructure costs as well as the removal of reference implementations. Jakarta EE 9 is a big incompatible release that offers users minimal value. The point was to move the platform to stage 1 of EE10. We need to remove the implicit assumptions and behaviors inherited from the JCP process and get to a sustainable ecosystem. On Mon, Jul 6, 2020 at 10:40 AM Werner Keil <werner.keil@xxxxxxx> wrote:
_______________________________________________ |