►
From YouTube: Jakarta EE Platform TCK call #25 November 2, 2022
Description
November 2, 2022 Jakarta EE Platform TCK call #25. Minutes can be viewed via https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit# continued talking about TCK refactoring. Guru suggests idea of using OpenRewrite to automate TCK refactoring at the test source level. Jan brought up semantic versioning impact.
A
In
in
you
know
in
the
agenda
that
people
can
click
on,
and
you
can
look
in
the
platform
mailing
list
for
that
discussion-
that
we
just
you
know,
kind
of
walk
through,
but
you
could
oh
sorry
yeah
we
did.
We
did
no
yeah
right
right.
We
I
had
shared
the
wrong
screen,
so
we
didn't
record
it.
Yep
I
will
yeah.
Let's
just
do
this
really
quick
I'll,
just
open
them
quickly
again,
so
they
will
be
in
the
recording.
A
A
A
A
That'll,
do
it
okay,
so
yeah,
so
it's
it's.
Some
notes
that
L,
when
entered
for
how
you
know
steps
to
do
the
tck
refactoring
based
on
our
past
experience
and
the
you
know.
The
great
thing
now
is
any
anyone
in
the
community
can
create
a
pull
request
against
this
content
to
make
further
changes.
They
don't
have
to
be
a
committer
on
the
platform
tck
to
make
a
change
and
I
think
that's
a
good
step
and
yeah
in
general.
Let's
see,
let
me
fix
the
link.
B
Yeah
yeah
I
mainly
do
the
fact
that
wikis
can
cannot
acceptable
request
right,
so
it's
better
to
have
it
outside.
Yes,
that's
a
big
issue
with
wikis
that
I
have
almost
always
had
I
I'm,
not
against
the
wikis.
Obviously,
but
if
you
want
to
publish
something
that
will
be
open
for
collaboration,
I
think
Wiki
is
not
the
better
place
to
to
have
them.
A
I
I
found
out
also-
and
you
know
in
the
last
week
or
so
that
yeah-
that
we
cannot
assign
tck
issues
to
people
that
aren't
recognized
as
contributors
in
in
some
way
and
so
I
I
I.
You
know
I
had
we,
we
had
a
a
couple
poll
requests
that
were
submitted
and
you
know
created
issues
for
you
know,
for
those
pull
requests
and
I
wanted
to
assign
them
to
the
the
you
know.
A
Is
the
road
map
issue
that
we
started
for
coming
up
with
Milestone
releases
and
epic
yeah
and
basically
at
you
know,
following
the
Epic
pattern
for
you
basically
having
you
know
a
bunch
of
issues
and
Milestones
releases
that
you
know
we
can
cut.
You
know
resolve
as
a
team
and,
let
me
just
say
at
a
high
level,
the
yeah
I'll
stay
here,
the
you
know
at
a
high
level.
A
The
you
know
a
a
big
idea
here
is
that
to
do
some,
you
know
refactor
some
platform
tck
test
in
each
of
the
different
test,
buckets
and
basically,
by
doing
that,
we
can
open
it
up
to
others
to
contribute.
Who
may
have
no
idea
of
how
the
platform
tck
internals
work
or
how
to
write
a
a
you
know,
tck
test
or
update
a
tck
test
to
you
know
to
you
know
to
run
on.
A
A
Once
we
have
yeah
once
we
have
like
a
few
joffer
se
style
tck
tests
and
a
few
Jakarta
EE
style
tests
for
each
of
the
test
buckets,
and
even
if
we
don't,
you
know,
get
that
going
and
yeah
right
away
for
all
the
test
buckets
you
know,
even
if
it's
slow
to
get
them
all,
you
know
started
it
can
get
the
community
help.
The
community
join
the
effort.
A
You
know
to
convert
other
tests
in
those
test,
buckets
to
also
be
runnable,
because
they'll
kind
of
be
able
to
see
how
it's
done
for
the
tests
that
have
been
converted
for
the
tests
that
haven't
been
converted.
So
we
can
kind
of
get
some.
You
know
we
can
get
some
progress
going,
yeah,
so
that's
kind.
That
was
so
that
was
kind
of
the
idea
of
you're
behind
like
like
refactor
or
a
small.
You
know,
and
these
are
not
in
any
order.
A
You
know
those
few
tests
that
are
that
should
still
work
with
EE
10
implementations,
because
we
won't
have
brought
in
any
spec
API
updates
or
ee
11
and
I
mean
and
yeah
I,
don't
yeah
time
and
wise
I,
don't
even
know
when
that's
gonna,
ee,
11,
spec
updates
will
even
be
ready
to
be
to
be
brought
in
or
to
be
considered
to
be
brought
in
but
anyways.
The
idea
is
that
this
Milestone
release
will
work
against
ee10
implementations
and
can
be
validated
against
any
ee10
implementation.
A
That's
willing
to
help
do
that.
Do
that
validation
to
see
that
yeah
yeah,
that
you
know
each
of
those
test
buckets
work
or
okay?
Maybe
you
know,
changes
are
needed
and
we
can
kind
of
you
know.
We
can
kind
of.
You
know
work
on
that.
You
know
we'll
get.
You
know
early
feedback
and
early
validation
of
that,
and
then
we
kind
of
oh
yeah,
this
some
other.
You
know
some
other.
You
know
you
know
things
as
well.
A
In
terms
of
you
know
whether
it's
a
a
a
standalone
spec
like
you
know,
age,
you
know
whether
a
specification
document
or
you
know
section-
you
know
doc
of
the
of
the
document
or
maybe
a
javadoc
assertion
and
would
like
to
kind
of
nail
that
down
to
into
a
way
that
you
know
we're,
you
know,
tests
can
be
updated
or
added
that
clearly
link
to
the
specifications
in
a
way
that
you
know.
You
know
that
that's
that
supports
in
progress
work.
A
A
A
You
know
I'd
like
to
have
one
one
email
that
I
can
send
that
contains
all
the
results
in
terms
of
the
number
of
tests
run,
the
number
of
tests,
yeah
yeah
past
the
number
of
tests
field-
and
you
know
you
know
I-
think
in
the
in
our
community
effort
to
test
to
validate
ee.
Not
you
know,
eight
nine
ten
there's
been
a
lot
of
manual
effort
to
kind
of
pull
those
stats
together.
A
A
A
A
If
we
reach
the
test
buckets-
and
you
know
the
the
thinking
there
is
just
trying
to
hit
some
of
the
hotter
cases
whatever
they
may
be
when
whatever
that
means,
and
so
have
a
third
Milestone
that
can
be
run
against
EE
and
implementations
to
validate
that
that
those
tcks
work
and
that
you
know
you
know
so,
there's
some
Java
SE
test
in
there
as
well.
So
that's
validation
that
can
be.
You
know
done
as
well,
if
a
third
Milestone
against
the
Standalone
specs
as
well.
A
So
so
we
kind
of
developing
a
pattern
here.
You
know
so
when
we
hit
this
third
Milestone,
we
have
you
know
yeah,
we
yeah.
We
we
have.
You
know
for
all
the
test
buckets.
We
have
something
working
and
something
we
can
build
on
and
for
the
four
fourth
Milestone
we're
going
to
take
us.
You
know
I.
You
know
this
is
all
subject
to
change,
but
yeah
we'll
take
a
shot
at
completing
the
SC.
B
B
A
What
what's
going
on
there,
but
up
up
above
and
in
other
discussions,
the
the
you
know,
the
there's,
a
chicken
and
egg
problem
of
between
the
spec
ballot
sets,
we've
done
them
in
the
past
and
the
Jakarta
ee
container
testing
and
the
the
the
chicken
and
egg
problem
is.
Let
me
see,
there's
a
quick
summary
in
here.
I
think:
let's
see
yeah
you're
right
right
here,
so
there's
a
it's
a
quick
summary
here
of
of
which
yeah
which
test
buckets.
A
A
So,
just
as
an
example,
the
connect
the
Standalone
connector
tck
at
when
we
hit
the
Milestone
three
released,
will
you
know
not
have
at
and
we
will
not
have
added
any
ee
ee
11
qck
test.
Yet,
but
we'll
you
know,
let's
just
say
hypothetically,
we
wanted
to
do
the
spec
Bell
for
connector
doing
the
stack
ballot
for
a
connector
means
that
that
we
can't
add
in
any
any
more
test
after
that
ballot
is
complete.
A
If
we
do
that,
and
we
won't
default
to
just
change
making
a
lot
of
changes,
but
the
idea
as
it
applies
to
the
eeel
11
release,
at
least
in
in
in
in
these
in
this
issue,
is,
let's
just
say,
for
connect.
Connector,
we
have
a
the
the
the
the
Standalone
connector
spec
ballot,
that
stats
and
it
completes
and
it's
considered
final.
Then
we
decide.
Oh,
you
know
what
we
want
to
add.
We
need
yeah,
we
need
to
add.
A
We
missed
adding
tests
for
connector
in
the
ee
container
on
in
the
you
know,
equivalent
of
platform
tck,
whatever
the
refactor
tck
is
going
to
be
called.
Let's
just
say,
platform
tck,
you
know,
assuming
that's
going
to
stay
as
a
name
to
add
those
tests
without-
and
you
know
without
you
know,
breaking
that,
possibly
breaking
that
that
implementation
that's
already
passed,
the
connector
test
is
a
you
know,
is
a
problem
to
solve.
A
So
the
thing
you
know
the
thinking
on
that
is,
allow
tests
to
be
changed
and
to
be
added.
You
know.
During
the
you
know,
ee
11
process
and
also
after
ee
11
goes
fine.
It'll
allow
tests
to
be
changed
and
even
added
in
in
in
some
fashion
and
the
way
that
that
makes
sense
for
after
El
ee
11
might
be
adding
alternate
tests,
and
we,
you
know
you
say:
okay,
we
can't
really.
A
We
can't
really
do
anything
but
exclude
this
exclude
a
test
or
you
know
change
it,
but
we
really
want
to
kind
of.
We
want
to
keep
the
current
tests.
You
know
for
for
compatibility
reasons
and
for
those
who
have
already
passed
and
want
to
have
a
new
version
of
that
test.
That
is
an
alternate
test
and
and
we're
not
saying
that's
going
to
be
requirement
or
that's
going
to
be
the
way
it's
going
to
be
done,
but
it's
just
a
possibility
and
you
know
to
be
figured
out
of
what
could
happen.
A
C
A
But
with
regard
to
you
know
whether
it's
a
surface
release
or
a
minor
or
a
major
with
regard
to
tck.
It
would
always
be
a
service
release
after
the
spec
has
gone
final.
So
so
after
ee
11
platform
has
gone
file,
it
would
it
would
definitely
be
a
service
release,
it's
a
bit
fuzzy
for
it.
Currently,
it's
a
bit.
You
know
fuzzy
and
unclear
for
a
lot
of
these
TC
Standalone
tcks
that
are
generated
by
the
platform.
A
Tck
like
let's
say,
for
the
example
we
of
connector
that
we
had
to
connect,
let's
just
say,
for
you
know,
going
back
for
the
ee10
release.
Let's
just
say
we
yeah,
we
yeah.
We
had
a
connection
that
we
went
through
the
connector
ballot
for
ee-10
and
it
was
connected,
was
finalized
and
we
decided
to
add
a
test
after
that.
Okay!
Well,
that's
you
know.
A
It's
that's
really
a
fuzzy
thing,
because
if
we
add
a
test
to
the
platform
tck
yeah,
we
have
to
be
careful
that
that
same
test
doesn't
show
up
in
the
Standalone
connector
tck
or
that
we
don't
accidentally
like
slip
it
in
in
a
service
request,
service
release
for
the
connector
tck
that
comes
out
later
and
it
it
it's.
You
know
it's
not.
You
know
it's,
it's
not
an
easy
thing
so
that
you
know
great
care
has
to
be
taken
to
avoid
those
kinds
of
problems.
A
So
do
a
lot
of
the
validation
and
development
in
the
communities,
but
you
know
don't
finalize
releases
and
call
them
final
until
all
the
changes
have
been
done
and
all
the
changes
don't
really
happen.
You
know
in
a
pro,
in
a
proper,
in
a
proper
new
ee
release,
tck
tests
will
be
added
up
until
near
the
end
until
we're
ready
to
freeze
it.
Somehow
that
would
have
to
align
with.
A
You
know
that
the
specs
going
final,
you
know
closer
to
the
end
after
everything's
been
worked
out
and
that's
where
that's
we,
so
that
would
be
that
would
I
think
that
would
be.
Basically
all
the
specs
that
depend
on
other
specs
and
implementations
that
depend
on
on
specs
would
be
working
off
of
Milestone
releases
that
are
all
available
in
the
community,
so
that
I
don't
know
there
may
be
other
ideas,
so
it
kind
of
gets
into
I.
I,
don't
know
if
that
helps.
A
C
Yeah
I,
really
like
with
the
idea
like
we
discussed
in
the
last
platform
meetings
too,
not
switching
off
tests
that
create
some
issues
simply
instead
refactoring
the
tests,
so
it
works
with
every
implementation
as
intended
or
maybe
in
some
cases,
tests
need
to
be
fixed
or
some
additional
configurations
need
to
be
done
to
run
the
tests
in
the
right
environment
or
configuration
and
things
like
that.
That's
way
better
than
yeah
just
skipping
or
removing
the
tests
from
the
tck.
D
C
D
A
A
A
Guru
suggested
at
one
point:
I
think
I,
don't
know
if
it
was
last
year
or
the
year
before
that
for
a
new
ee
release,
one-way
of
of
you
know,
testing
a
a
new
spec
API
is
to
take
an
existing
implementation
and
kind
of
plug
in
the
change.
Spec,
API
and
kind
of
you
know
use
it
with
the
implementation
and
yeah.
A
If
that
works
and
that
yeah,
you
know
I
I,
think
that's
yeah
yeah,
the
you
know
basically
validating
off
of
a
working
system
is
the
idea
there
and
that
really
stuck
with
me
that
in
that
idea
and
I
you
know
it's
kind
of.
You
know
that
yeah
it's
it's
really
really
different
than
what
we
did
for
ee9
and
and
ten.
A
B
A
D
Scott,
basically
for
migration,
since
the
repository
and
the
code
base
is
huge,
if
we
automate
some
of
the
migration
like,
we
will
be
doing
repeated
source
code,
changes
for
adding
junit
or
equivalent
technology
to
replace
the
J
test,
so
automation
of
the
source
refactoring.
If
we
can
use
the
some
of
the
tools,
then
it
will
be
great.
I
have
I
came
across
one
of
the
tools
today,
I'm
pasting
it
in
chat.
It
is
called
open
rewrite
it
has.
D
They
have
rules
for
migration
of
from
junit
4
to
J
unit
5,
but
since
we
also
have
patents
in
the
my
refactoring,
like
some
of
the
tests
will
have
new
annotations
of
junit,
all
the
tests
will
have
new
annotations
of
j
in
it.
I
feel
automation
of
some
of
the
some
part
of
the
refactoring
will
speed
up
the
process
and
will
help
us
in
achieving
the
goal
which,
which
we
are
trying
for
Jakarta
11
much
faster.
D
So
so
we
have
patterns
like
we
need
to
introduce
some
of
the
annotations
in
the
test
and
we
have
patterns
like
we
need
to
remove
some
of
the
junit
J
Test
code
and
also
we
have
to
reformat
some
of
the
login
aspects.
So
some
some
aspects
can
be
automated.
I,
don't
know
it
till
how
far
we
can
go
with
automation,
but
I.
C
A
D
A
D
It
has
some
rules:
I
haven't
I
came
across
it.
This
tool
recently
I
haven't
ex
gone
through
internal
details,
but
some
of
the
rules
seem
to
be
like
for
migration
from
jdq
11
to
jdk,
17
or
junit
5
to
junit
Janet,
four
to
Janet
Phi
or
some
rules
they
have
already
built
in
are
for
spring
migration
from
older
version
of
spring
to
newer
version.
So
if,
if,
if
we
can
explore
these,
the
tool
called
open,
open
rewrite
it.
D
C
That's
a
great
idea:
what
I
would
like
to
have
when
starting
using
the
tooling
for
migration
have
the
possibility
to
test
that
components
back
tests
before
and
after
the
refactoring,
so
it
generates
the
same
test
results.
So
we
can
be
sure
that
the
refactoring
works
well
and
not
create
additional
issues
that
may
be
hard
to
find.
If
that
is
done
in
an
automated
way,.
C
A
A
Know
to
have
to
just
to
kind
of
like
take
the
drudgery
out
of
the
work
and
like
like
just
the
package
rename
from
java
X
to
Jihad,
or
you
know
that
that
was
I.
Forget
I,
forget
the
the
exact
number
of
them,
but
yeah
we
had
yeah.
We
had
many
pull
requests
that,
were
you
know,
sixty
thousand,
you
know
lines
updated
and-
and
it
was
you
know
so
you
know
some
as
small
as
ten
thousand
lines.
A
B
A
It
would
be,
you
know
it
would
be
a
huge
yeah,
huge
plus,
so
we
don't
have
to
manually
update.
You
know,
you
know
two
to
four
million
lines
of
you
know
of
test
and
and
so
yeah.
That's
great
good,
great
suggestion.
I
love,
it
I
love
it
really.
And
let's,
let's
note
the
idea
too.
So,
let's
see,
let's
see
you
know
of
validating
so
Valley
and
validation.
A
A
A
I,
don't
think
we've
changed
package
name,
so
we
may
have
changed
some
packagings
I
I,
honestly,
don't
remember
it's
yeah
been
it's
been
a
long
time
since
we've
actually
have
been
changing.
You
know
doing
the
refactoring.
It
was
at
the
beginning
of
the
ee's
Henry,
at
least
when
we
were
doing
that,
and
then
we
kind
of
putting
out
pies
that,
but
so
so
yeah
it
yeah
I,
don't
yeah
so
I
don't
know,
but
yeah
so
run
test.
Before
and
after
the
refactoring
and
compare
results.
B
A
A
It
would
not
work
because
yeah
we
would
basically
in
order
to
for
E,
for
that
to
you
for
for
this
to
work
with
EE
11,
we
would
need
in
ee
11
implementation
of
the
not
refacted
platform
dck,
and
it
sounds
like
from
the
start
of
the
ee
11
release
until
the
very
end
everyone
available
to
help
will
be
busy
with
refactoring
unless
the
automation
just
works.
So
you
know
you
know
so
wonderfully
that
you
know.
A
You
know
that
it's
you
know,
you
know,
that's
not
the
case,
but
I,
don't
know
I,
yeah
I,
don't
think
I,
don't
I
I!
Really
you
know
if
they're,
if,
if
there,
if
there
are
contributors
that
want
to
work
on
the
ee-11
platform
tck,
you
know
the
not
refactored
that
would
be.
You
know
that
could
work
but
I,
don't
know
it.
It
I
guess.
There's
a
question
mark
I'll,
put
a
question
mark
on
that,
let's
say,
might
not
might
not
work.
A
You
know
the
you
know
the
you
know
the
the
ones
that
have
to
offer
SC
tests
because
yeah
one
one,
you
know
we
don't
we
don't
want.
You
know.
Let's
say
we.
Let's
say
we
move
the
connector
tck.
We
you
know.
Basically,
this
exercise
we're
gonna
we're
gonna,
basically
end
up
with
basically
a
standalone.
A
You
know
Ace
almost
r,
a
standalone
project
for
a
connector
to
have
its
own
tck
with
a
the
connector
spec
takes
that
or
not
I
think
they
would
take
the
SE
and
the
ee
container
test,
or
maybe
not.
Maybe
they
would
only
take
the
SC
test.
It's
really
it.
It's
a
there's,
a
discussion
there
yeah
that
I,
don't
really
have
the
answers.
I
think
it's
better
to
have
them
together,
but
in
some
sense
it's
better
to
have
them
not
be
together.
A
So
the
yeah
there's
pluses
and
minuses
to
to
either
way
but
but
I
think
it
could
go
either.
It
could
go
either
way.
You
know
so
the
SC
tests
you
know
could
move
to
the
spec
the
SC
test
and
the
ee
tests
could
move
to
that
spec
or
they
could,
you
know,
stay
in
the
they
could
stay
in
the
platform,
tck
project
and
be
maintained.
There
I
think
it's
better
if
they
move
to
the
Standalone
spec,
that's
kind
of
what
we're
working
towards.
A
But
you
know
not
every
not
every
spec
will,
you
know
is
active
enough
to
you
know
you
know
for
that
to
work,
I
think
so
it's
just
not
it's
not
clear.
It's
not
yeah.
We
we
can
make
decisions
on
that,
but
I
don't
think
it's
you
know,
I
think
it's
like
a
that's
more
of
a
platform
level
discussion
and
there
is
a
platform
issue
for
how
to
handle
that
that
we
opened
for
ee10
and
we
just
never.
We
we
there
was
discussions
on
it.
A
I
forget
the
number,
but
it
it's
basically
all
about
how
how
we
do
integration
testing
at
the
platform
level
in
Standalone,
tck
test
like
like
we've
done
in
in
in
in
you
know,
like
you
know,
rest
yeah
rest
is
obviously
doing
it.
Restful
web
services
is
doing
it,
I
mean
batch
is
doing
it
somewhat
and
other
others
are
doing
it
and
then
some
other
Tech,
some
other
specs
chose
to
have.
A
C
It's
in
general
I
think
I
would
agree
having
tests
that
are
specific
to
one
component
spec
or
the
components
back
and
its
own
dependencies
should
be
placed
beside
that
components
back
and
maybe
there
are
different
tck
artifacts
for
different
environments
that
need
to
be
passed
when
it
should.
The
test
should
be
on
the
lowest
possible.
A
It's
it's
it.
The
the
dependencies
are
yeah
is
really
difficult.
You
know,
I
should
say
you
know
they
yeah,
but
if
we
could
have
SP,
you
know
yeah,
maybe
like
too
late.
You
know
two
like
two
levels
of
interface
like
like
a
low
like
low
at
the
bottom
like
like
spis
and
then
no
other
specs
depend
on
anything
other
than
the
sbis
I.
Don't
know
or
something
like
that.
A
A
It's
yeah
it
just
yeah.
You
know
we
yeah.
We
have
to
make
improvements
and
and
decide
what
those
are
and
so
I
think
this
I
think
this
plan.
You
know
it's
taken
a
shot
at
the
you
know
at
the
platform
pck
plan,
once
we
have
a
plan
for
the
ee
11
release
in
general,
then
you
know
this
point
yeah.
The
platform
tck
refactoring
plan
can
align
to
that
yeah
and
other
discussions
that
happen,
but
oh
we're
out
of
time.