[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] Component spec review deadline and when to create 3.1 RC1 and staging of final
|
Hi Kyle,
I discovered the processor, it's a bit confusing at the first
reading. The issue was in my test setup, libs copied to the
server.
Tests run: 249, Failures: 5, Errors: 10, Skipped: 25
I'm currently investigating the other issues. Don't know the
reasons so far, no known TCK issues right now.
Petr
On 3/19/24 6:31 PM, Kyle Aure via
cu-dev wrote:
After further investigation it does seem that we assume the
JDK version of the Client and the JDK version of the Container
are the same.
So it is conceivable that if you were to run this test from
a Java 17 client, while your server is running on Java 21 you
would fail the signature test.
If this is the case we could fix the signature test to make
the decision of which signature file to test against until
runtime inside the container.
I just ran the signature test using a locally built
snapshot against Open Liberty using Java 21 and had no
failures.
Hello Ondro,
Thanks for the update.
The class that you pointed to
ConcurrencySignatureTestRunner.java is part of an
arquillian test which gets deployed to a container.
When we deploy the application to the container we find
the appropriate signature file and rename it to a generic
file called `jakarta.enterprise.concurrent.sig`.
I wonder if the real issue here isn't just one of
inadequate ignoring of JDK classes.
Let me do some more testing on my side to see if I can
replicate any issues.
Thank you,
Kyle Jon Aure
Hi Nathan, Kyle,
The test should adapt to the version of Java in the
runtime and choose the correct signature file.
Ondro
Petr and anyone else
who is experiencing issues with the
Concurrency 3.1 signature tests, please see
Kyle’s request below regarding providing the
details. Please get this information to him
as soon as possible. Now that Kyle is back,
he might be able to fix the issue you are
seeing if you can provide the necessary
information to reproduce it. If it is not
addressed in time, we will need to decide
between holding up RC1 and staging a copy of
final, which will cause us to miss the
component specification deadline for Jakarta
EE 11, vs moving forward to meet the
deadline.
Hello
All, Sorry I was out last week and am
just now getting caught up on this.
Petr, what failure are you getting
from the signature test for
concurrency? Is it that the signature
test is not correctly finding the
concurrency API on your classpath?
This
Message Is From an External
Sender
This
message came from outside your
organization.
Sorry I was out
last week and am just now getting
caught up on this.
Petr, what failure
are you getting from the signature
test for concurrency?
Is it that the
signature test is not correctly
finding the concurrency API on your
classpath? Or is it failing due to
insufficient ignoring of JDK classes?
If you could open
an issue with more details I will be
happy to address it prior to the RC1
release.
On 3/14/24
16:37, Scott Stark via cu-dev
wrote:
For CDI and
Validation we setup a
maven project just to set the
classpath for the type of
signature dependencies we want
to validate. For example, just
the dependent CDI API jars:
For the
jars that Weld depends on:
I did not
look into how the
SigTestDriver class actually
does the testing. Is this
using the netbeans sigtest
code or the jakarta tck tools
fork, or something else?
It was using netbeans sigtest
before but looks like Faces 4.1 is
using jakarta tck tools fork as per
https://github.com/jakartaee/faces/blob/4.1/tck/faces-signaturetest/pom.xml#L55
It's
possible, but we'd need to
change how the class path is
resolved. It shouldn't
really resolve from Maven
Projects class path, the
class path should be
required to be provided and
point to server
dependencies. Another idea
might be to provide an
abstract Arquillian test
which can check that a
deployments class path is
setup correctly.
Can
this just be rolled into
a run mode of the tck
tools sigtest maven
plugin?
Hi,
The signature maintainers did some amazing work after
the fork :)
That would make it even easier to reuse the signature
creating and
testing
between
projects.
I don't want to distract from the main point of this
conversation too
much, but I just
want to add a +1
to that. I know
other projects
would benefit
from that as
well.
I think
that we also
need to update
"excludeJdkClasses"
tck/src/main/java/ee/jakarta/tck/concurrent/common/signature/SigTestDriver.java
to include the
same classes
added by the
https://github.com/jakartaee/concurrency/pull/393
change which I
think will
help us pass
Concurrency
3.1 Signature
Tests on Java
21.
We also
need to update
the Signature
test tooling
to better
ignore the
Java SE
classes so
that we don't
have to spend
time on
changes like ^
in the future.
On 3/14/24 12:21, Arjan Tijms via cu-dev wrote:
Hi,
Regarding the Signature tests, I recently did them for
the upcoming
Faces 4.1 TCK.
It should be relatively easy to copy that over to the
Concurrency
TCK and adjust
the package
and API names
where needed.
Petr,
That’s great to hear. It sounds like you are very
close to
having it all
passing! Are
you also
covering Java
17, or only
21? We will
need to have
passing TCK
results from
compatible
implementations
on both Java
SE levels
given the
decision that
was made at
the platform
level about
requiring Java
17. If not,
it is an
option to have
different
compatible
implementations
per Java SE
level when we
submit for
component spec
release
review.
Regarding the signature tests, I assume we would not
be allowed to
not have them
at all. I’ll
let Kyle
comment on the
signature
tests because
he has been
more involved
in them. He is
out for a day
or two but it
is back next
week.
Hello Nathan,
Concurro is
heading
towards
implementation
of 3. 1. We started to execute the TCK in
Payara,
currently with
result: Tests
run: 242,
Failures: 5,
Errors: 4,
Skipped: 24
With Ondro, we
did the Flow
support today
(PR in
Concurro).
Hello
Nathan,
Concurro is
heading
towards
implementation
of 3.1. We
started to
execute the
TCK in Payara,
currently with
result:
Tests run:
242, Failures:
5, Errors: 4,
Skipped: 24
With Ondro,
we did the
Flow support
today (PR in
Concurro).
Some fixes
were done in
TCK itself,
there is
definitely one
more error in
testSignature.
The work
will continue,
so I think
that
Concurro+Payara
can serve as
the compatible
implementation
on Java 21. It
will at least
test the TCK.
I also plan to
add the
required parts
to Glassfish.
Regarding
SignatureTests
-- are we
going to work
on it? I am
convinced,
that we
discussed its
removal, but
there were
some changes,
so it looks
like we are
going to adapt
it to Java 21?
Petr
On 3/11/24 9:45 PM, Nathan Rauh via cu-dev wrote:
As a Jakarta EE 11 specification in wave 6, Jakarta
Concurrency
3.1’s deadline
for component
specification
release review
is April 27,
2024. It
might sound
like is it
still a ways
off, but it
requires our
specification
to publish
fully passing
TCK results on
Java 21 and 17
from a
compatible
implementation
alpha, beta,
or GA release
with publicly
available
download,
after having
pushed a
candidate
final copy of
the
specification
to staging
that can be
published upon
successful
review.
We need to come up with plans for what our compatible
implementation
is expected to
be and line it
up with these
dates.
In order for Open Liberty to be a compatible
implementation
for
certification
of Jakarta
Concurrency
3.1, our
release
process would
require a 3.1
RC1 to be
created by
March 20th,
after which
the API,
specification
requirements
(and
preferably
TCK) must not
change. This
would allow
for the
creation of a
downloadable
beta release
that will
become
available in
time to
officially
pass the TCK
and post
results by the
component
specification
deadline.
Are there any other implementations that could be
candidates to
use for
certification
of 3.1?
I noticed there has been a lot of work in the Concurro
implementation. Someone who is working on it would need to let us know
how it lines
up with the
wave 6
component spec
release review
deadline.
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing
list
cu-dev@xxxxxxxxxxx
To unsubscribe
from this
list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing
list
cu-dev@xxxxxxxxxxx
To unsubscribe
from this list,
visit https://www.eclipse.org/mailman/listinfo/cu-dev
--
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from
this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
--
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
