| Re: [jakarta.ee-spec.committee] Jakarta EE 9.1 release is in jeopardy... |
From a GlassFish perspective I’m not aware of “basic issues that are preventing any meaningful results” I know there has been a mail about the ACC for EJB testing? We don’t currently have any open issues raised by the TCK team.
Steve
From:jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter
Sent: 25 February 2021 17:52
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: [jakarta.ee-spec.committee] Jakarta EE 9.1 release is in jeopardy...
Hi,
Just this week, my eyes have been opened to the fact that our Jakarta EE
9.1 goal of a March 25 release is in jeopardy. As of Tuesday morning,
we still have zero results for the GF 6.2 and TCK runs. Tests are
executing, but there are still some basic issues that are preventing any
meaningful results.
If we work backwards from March 25, the two week ballot for the 9.1 release
would have to start on March 10. And, given that Feb is a short month,
that is less than two weeks away. Going from essentially 0% passing
to 100% passing in less than two weeks would be a miracle. As much
as I like miracles, I just don't want to count on that to meet this goal.
On our calls this week, I did mention that Open Liberty is at 99.9% passing
with the 9.1 TCK and Java SE 11. The main issue is with the Signature
tests. We have a workaround to make these work, but we are still
working with Scott Marlow to figure out a proper solution for the TCK.
Also, given our current process, Open Liberty could not be the CI
for ratification because we do not implement the optional Entity Beans
feature.
One idea is to use a tag-team approach for certifying... Focus on
GF 6.2 providing test coverage for Entity Beans and OL being used for everything
else. We've talked about allowing this co-CI approach in the past,
but I'm not positive that our process would currently allow for this. It
reads pretty specific to a single CI:
Compatible
Implementations
A Compatible Implementation must fully implement all non-optional elements
of a Specification Version, must not extend the API (no supersetting),
and must fulfill all the requirements of the corresponding TCK. A Specification
Version must identify at least one Compatible Implementation under an Open
Source License that implements all optional elements of the Specification
and fulfills the requirements of all elements (including optional elements)
of the TCK.
But, if I look at the figure in the Ratification section of the EFSP, next
to the Compatible Implementation box it does use the 1..n notation.
Maybe I'm just fishing for an alternative solution... And, maybe
we'll get the magic results for GF and the TCK before the weekend... But,
if we are intent on sticking to this March 25 goal, something's going to
have to give...
We'll have to start this discussion now via this email distribution since
we don't meet again "in person" until the deadline of March 10...
Thanks!
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee