We can do that indeed, not all have been brought in. It depends a little on the speed of the reviews though.
Hi,
As we're very likely not going to meet
the target of releasing GlassFish 6.1.0 final tomorrow, shall we at least
do a M1 again?
If there's no objections I'll release
one soon. I can start with simple staging.
Kind regards,
Arjan Tijms
On Mon, Mar 1, 2021 at 6:15 PM arjan
tijms <arjan.tijms@xxxxxxxxx>
wrote:
Hi,
It's, at least for me, no super big blocker
now not having updated TCK jobs on the GlassFish CI. I'll keep an
eye on https://github.com/eclipse-ee4j/glassfish/issues/23396 Thanks!
Kind regards,
Arjan
On Mon, Mar 1, 2021 at 6:03 PM Scott
Marlow <smarlow@xxxxxxxxxx>
wrote:
Can we work around not yet having updated
TCK jobs on the GlassFish CI?
See more responses inline below.
On 3/1/21 9:57 AM, Steve Millidge (Payara)
wrote:
I think it would help being able to run
these on Jenkins. I’m not sure how far Guru got with finishing the TCK
jobs. I think we also need help from the TCK team as from a GlassFish perspective
the Quick Look tests are passing.
The problem that we have been having
is that Jenkins collection of the test failures is impacted by the number
of failures. There is also a Jenkins error collection plugin that
stopped working which we disabled as we can collect the errors without
it but less easily.
Alwin is going to try some changes for
the GlassFish client container failures on JDK 11 (https://github.com/eclipse-ee4j/glassfish/issues/23396).
From: jakarta.ee-spec.committee
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>On Behalf Of arjan tijms
Sent: 01 March 2021 14:55
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>;
glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Jakarta EE 9.1 release is
in jeopardy...
Hi,
I've tried some fully standalone TCK
tests:
Jakarta Servlet
2 failures
[javatest.batch] Number of Tests
Passed = 1683
[javatest.batch] Number of Tests
Failed = 2
[javatest.batch] Number of Tests
with Errors = 0
API_download=https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/servlet/jakarta.servlet-api/5.0.0/jakarta.servlet-api-5.0.0.jar
Product_download=https://ci.eclipse.org/glassfish/view/GlassFish/job/glassfish_build-and-test-using-jenkinsfile/job/master/lastSuccessfulBuild/artifact/bundles/glassfish.zip
TCK_download=https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-910/jakarta-servlet-tck-5.0.0.zip
Issue: https://github.com/eclipse-ee4j/jakartaee-tck/issues/625
Jakarta Pages:
2 failures:
[javatest.batch] Number of Tests
Passed = 700
[javatest.batch] Number of Tests
Failed = 2
[javatest.batch] Number of Tests
with Errors = 0
API_download=https://jakarta.oss.sonatype.org/content/repositories/staging/jakarta/servlet/jsp/jakarta.servlet.jsp-api/3.0.0/jakarta.servlet.jsp-api-3.0.0.jar
IMPL_download=https://jakarta.oss.sonatype.org/content/repositories/staging/org/glassfish/wasp/wasp/3.0.1/wasp-3.0.1.jar
Product_download=https://ci.eclipse.org/glassfish/view/GlassFish/job/glassfish_build-and-test-using-jenkinsfile/job/master/lastSuccessfulBuild/artifact/bundles/glassfish.zip
TCK_download=https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-910/jakarta-pages-tck-3.0.0.zip
Issue: https://github.com/eclipse-ee4j/jakartaee-tck/issues/624
Jakarta Faces:
0 failures
[javatest.batch] Number of Tests
Passed = 5525
[javatest.batch] Number of Tests
Failed = 0
[javatest.batch] Number of Tests
with Errors = 0
Product_download=https://ci.eclipse.org/glassfish/view/GlassFish/job/glassfish_build-and-test-using-jenkinsfile/job/master/lastSuccessfulBuild/artifact/bundles/glassfish.zip
IMPL_download=https://jakarta.oss.sonatype.org/content/repositories/staging/org/glassfish/jakarta.faces/3.0.0/jakarta.faces-3.0.0.jar
TCK_download=https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-910/jakarta-faces-tck-3.0.0.zip
Jakarta Authentication
85 failures
[javatest.batch] Number of Tests
Passed = 22
[javatest.batch] Number of Tests
Failed = 85
[javatest.batch] Number of Tests
with Errors = 0
Most failures because of
[javatest.batch] java.lang.Error:
org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader
[javatest.batch]
at java.lang.ClassLoader.initSystemClassLoader(java.base@11.0.2/ClassLoader.java:1989)
[javatest.batch]
at java.lang.System.initPhase3(java.base@11.0.2/System.java:2066)
[javatest.batch] Caused by: java.lang.ClassNotFoundException:
org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader
[javatest.batch]
at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@11.0.2/BuiltinClassLoader.java:583)
[javatest.batch]
at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@11.0.2/ClassLoaders.java:178)
[javatest.batch]
at java.lang.ClassLoader.loadClass(java.base@11.0.2/ClassLoader.java:521)
[javatest.batch]
at java.lang.Class.forName0(java.base@11.0.2/NativeMethod)
[javatest.batch]
at java.lang.Class.forName(java.base@11.0.2/Class.java:398)
[javatest.batch]
at java.lang.ClassLoader.initSystemClassLoader(java.base@11.0.2/ClassLoader.java:1975)
[javatest.batch]
at java.lang.System.initPhase3(java.base@11.0.2/System.java:2066)
Jakarta Authorization
[doesn't run, fails and aborts in
setup stage]
Some help in getting
this over the line would certainly be helpful.
Kind regards,
Arjan
On Thu, Feb 25, 2021 at 9:55 PM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:
Thanks, Steve.
I'm really just asking for a more concrete status. Not sure if that's
coming from the TCK team or the GF team, or a combination. Maybe
we are closer to the 99% end rather than the 0% end, but I really don't
know and I didn't know where to look. And, when I reviewed the dates
and the calendar, I started to get nervous and threw out this note.
I'd love to be proven wrong so that we can all sleep better.
---------------------------------------------------
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)
From: "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 02/25/2021
14:02
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Jakarta EE 9.1 release is in jeopardy...
Sent by: "jakarta.ee-spec.committee"
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
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
_______________________________________________
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
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
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_______________________________________________
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
_______________________________________________
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