►
From YouTube: Jakarta EE 9 Release Roadmap | 2019-11-13
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Our
aim
is
to
have
you
know,
someone
who
leads
it
and
someone
who
insists
so
I've
volunteered
to
assist
by
you
know
giving
moral
support
to
the
lead
and
that's
pending.
So
again
this
is
all
community.
So
what
I'm
saying
is
you
know
my
view
of
where
this
is,
but
I
am
in
many
of
these
committees
and
things
so
I.
You
know,
I
have
a
pretty
broad
view
of
where
we're
at
at
the
moment.
A
So,
let's
just
wanted
to
sort
of
recap,
as
it's
a
sort
of
community
call
of
where
we
are
now
so
obviously,
the
Carter
e8
was
released
just
in
time
for
code
1
and
that
obviously
gives
us
full
compatibility
with
Java
8.
So
the
aim
was
to
have
it
to
be
binary
compatible
so
that
we
could
state
that
Carter
e8
was
binary,
compatible
Java,
EE
8,
one
of
the
big
things.
Obviously
now
I
was
you
just
seen
on
the
last
two
conversations.
Is
the
specifications
in
our
open
source
open?
A
There
are
on
github
and
they're
all
following
an
open
process
which
is
Jakarta
respec
process
and,
as
Irena
Marcus
said,
they're
all
willing
to
pull
requests
to
assist
in
in
moving
these.
The
other
big
big
piece
of
Jakarta
e8,
obviously,
is
the
open
source
TCK
license
and
the
open
source
process
and
the
fact
that
we
can
actually
see
the
food
for
the
TCK.
A
That
is
a
huge
change
from
where
we
were
with
Java
8
and
finally,
we've
got
a
set
of
compatible
implementations
in
Jakarta
ee.
You
have
to
have
an
open
source
compatible
implementation
to
have
a
specification
and
that
that
that
impacts
to
Carter
e9
as
well,
which
we'll
see,
but
at
the
moment
we
have
four.
So
we
have
Eclipse
GlassFish,
open,
Liberty,
PI,
R
server
and
wild
fly.
A
So
now
now
that
that
was
done,
that
has
been
a
bit
of
a
lull,
as
everyone
had
you
know,
took
some
breathing
space
and
went
to
many
conferences,
but
now
we're
turning
our
minds
to
Carter
e9.
So
this
is
sort
of
my
view
of
how
I
see
the
various
releases
that
we've
got
over
the
next
year
or
so
so
Carter
e8,
as
I've
said,
that
was
the
compatibility
release.
That's
the
release.
That
is
the
same
as
Java
EE
8
Carter
89
is
really
what
with
calling
a
sort
of
tooling
release,
which
I'll
explore
a
bit.
A
More
actually
9
will
be
the
namespace
change
and
we
have
to
move
so
any
API.
We
want
to
evolve
or
change.
We
have
to
move
from
the
direct
namespace
to
the
Jakarta
namespace,
so
the
focus
it's
got
to
be
nine
long
to
get
that
done
and
the
other
focus
will
be
deprecated
and
removal
of
a
bunch
of
old
api's
specifications
which
again
I'll
cover
a
little
bit
later
it
in
sort
of
my
view.
A
One
of
the
goals
are,
one
of
my
goals
have
been
pushing
for
and
in
various
committees
is
for
two
Carter
e92
to
lower
the
barrier
of
entry
for
it
for
new
players
in
the
market.
So
the
more
things
we
can
remove
that
are
not
really
used
anymore.
The
more
things
that
any
new
person
wanted
to
get
compatibility
will
have
to
implement.
A
A
A
A
That
doesn't
mean
that
you
know
we
don't
do
any
changes
to
API
so
about
all,
although
that
hasn't
you
decided
and
agreed
yet,
but
it's
possible
that
we
allow
up
with
compatible
changes
and
some
bug
fixes
and
clarifications
those
sort
of
things.
The
other
big
piece
is
the
namespace
change.
So
the
reason
we're
sort
of
saying
this
is
a
tooling
release
is
that
it
will
give
a
stable,
stable
point
for
IDs
to
sort
of
build
tooling.
A
If
doing
a
move
would
be,
you
know
just
due
to
namespace,
so
they
haven't,
they
haven't,
got
compile
errors
due
to
you
know,
things
being
removed
or
behaviors
changing
or
API
is
changing
drastically.
So
it's
the
goal
really
for
decart.
We
9
is
to
target
it
as
a
as
a
stable
point
in
this
transition
over
to
the
new
namespace.
A
A
What
is
the
planning
that
getting
done
at
the
moment?
So
the
steering
committee
has
made
a
mega
resolution
and
a
couple
of
weeks
codes
asking
platform
team,
which
is
the
project
team
and
the
open-source
side
that
is
responsible
for
delivering
the
platform
specification
and
that
team
needs
to
deliver
a
plan
to
the
steering
committee
by
December,
the
9th
and
for
the
release
of
Dakar
tree
9,
and
that
plan
will
have,
to
you
know,
put
a
line
in
the
sand
of
which
date
that
we
are
aiming
for
for
the
release
of
Dakar
tree
9.
A
So
the
interesting
thing
about
car
tree
9
is
a
lot
of
talk
about
cadence
and
things
for
decart
eee
and
whether
to
follow
a
release,
train
model
or
what,
but
for
two
carter
e9,
the
scope
is
fixed.
You
know,
there's
certain
specifications
that
we
need
to
migrate
over
to
a
new
namespace.
So
what
we're
gonna
have
to
do
is
essentially
determine
the
date
because
the
scopes
fixed,
so
the
dates
gonna,
have
to
move
around
the
fixed
quantum
of
work
that
we
have
to
do
so
purely
on
a
sort
of
analysis.
Point
of
view.
A
What
how
do
we
come
up
with
a
date
and
again,
we've
only
just
started
the
calls
about
this
in
the
platform
development
group,
one
of
them
was
yesterday.
One
thing
we
need
to
do
is
we
need
to
do
dependency
analysis
as
Marcus
and
Arian
shown
just
on
the
specification
level.
Specs
depend
on
other
specs
and
a
namespace.
You
know
API
is
in
a
dependent
of
the
api's,
so
we
need
to
look
at
the
dependency
analysis
tree
of
for
this
main
space
change.
A
You
can
have
already
done
a
PR
for
this
on
concurrency,
which
doesn't
depend
on
much
else.
So
that
was
very
easy,
but
obviously,
if
you
depend
on
another
API,
you
can't
change
your
API
definition
until
I
API
is
changed
as
well,
and
these
will
all
need
to
be
staged
so
that
you
can
refer
to
it
through
maven,
so
we're
gonna
have
to
go
for
a
model
where
we
take
the
dependency
analysis.
A
Obviously,
a
major
piece
of
work
will
also
be
the
the
big
platform
TCK
project.
There
are
a
few
TCK
projects
for
that.
One
is
going
to
need
a
lot
of
work
once
all
art
staged.
Artifacts
are
available,
so
that
bat
can
then
be
converted
and
there's
a
chicken
and
egg
here
around
TCK
passing
T
CK's
and
obviously
changing
our
api's
and
finally,
the
other
big
thing
that
is
required
to
actually
do
a
final
release
of
dakari
9.
It
will
be
a
compatible
implementation
that
implements
all
the
specifications
and
then
passes
the
full
platform
TCK.
A
A
Also,
as
a
final
thing.
We
are
prioritizing
early
delivery
over
any
changes,
so
feature
changes
or
backwardly
compatible
changes.
So
essentially
we
want
to
pick
the
earliest
possible
date
we
can
have
in
2020-
and
hopefully
at
least
first
half
2020,
so
you
anything
that
could
slow
it
down.
We
will
postpone
and
aim
to
you
know
people
should
prioritize
speed
over
anything
else,
so
going
digging
a
little
bit
into
what
we
see
is
the
content
to
car
three
nine.
A
A
A
We've
also
sort
of
agreed
that
backward
compatibility
will
be
a
runtime
concern,
so
that's
backward
compatibility
to
an
applications
still
using
with
Jeff
X
the
original
dev
X
namespace,
rather
than
imposing
it
on
a
specification
level.
We
will
leave
that
to
the
market
for
runtimes
to
support
old
applications
running
in
a
namespace
again
mainly
to
prevent
the
need
for
any
new
players
going
forward
to
have
to
support
our
old
applications,
because,
if
you
put
it
in
the
spec,
it's
probably
gonna
live
there
from
for
many
years.
A
B
A
Have
concerns
out
of
the
way
on
that
one,
oh,
what's
being
proved,
I
won't
read
them
all
out,
but
essentially
some
of
the
old
XML
specifications,
some
of
the
old
administration
and
specifications
like
deployment
and
management
and
the
old
egb,
2.1
and
area
work,
as
well
as
the
old
web
services.
Spec
that
isn't
really
used
anymore,
so
they'll
be
removed
again.
Will
we'll
have
a
vote
on
that?
Just
to
confirm
that
I?
Don't
think
it's
particularly
controversial
and
like
say
I
did
edit
from
se8
will
be
X
more
binding
in
an
activation.
A
So
that's
what
would
be
in
Jakarta
9
so
from
a
coterie,
10
perspective.
I
would
see
this
as
a
feature
release
and
the
important
thing
really
from
which
Carter
e
10
perspective
is.
We
can
start
that
work
now
in
all
the
specifications,
and
you
know
it's
encouraged
for
projects
to
do
start
doing
e
10
work
as
well
as
you're
doing
the
ee9
namespace
migration.
A
So
this
can
work
in
parallel.
I
suspect
that,
but
again
this
needs
to
go
out
for
conversation
and
review.
That
e
10
will
follow
more
of
a
release,
train
model
in
that
the
day
date
will
likely
to
be
fixed
and
the
scope
adjusted
depending
on
when
specifications
are
available
and
have
updated
and
can
do
a
release
to
meet
that
release.
A
A
A
Looking
for
the
contribute
and
I
think
every
project
is
absolutely
up
for
more
more
committees,
more
contributors,
but
in
the
first
instance,
the
platform
there.
The
list
is
covers
the
sort
of
platform
specification.
So
you
can
join
that
if
you
want
to
know
what's
happening
on
their
release,
planning
and
progress,
there's
a
general
community
list
and
then
every
single
project
and
specification
has
their
own
training
list
typically
expect
name
dev
everything's
on
github,
it's
all
open
source
as
as
Marcos
and
Irene
said
they
all
willing
to
have
pr's.
A
You
can
raise
issues
and
each
API
how
to
get
hub
repos.
If
you
want
to
do
some
namespace
change
work,
then
you
know
just
just
go
for
it
about
I
know.
A
couple
of
api's
have
got
PRS
by
people
want
currently
committed,
and
that's
you
know
it's
good.
You
know
it's
good
for
everybody,
so
yeah.
Where
is
it,
definitely
call
to
action
for
it's
for
people
to
get
involved
and
help
us
involved
Carter
II
thanks.
B
Yes,
t
fight
is
that
we
I
I
can
tutor
and
I
want
to
contribute.
I
have
a
lot
of
specifications,
yeah,
look
if
there's
some
work
needed
and
there's
a
platform
which
would
be
the
best
way
to
look
for
what
is
it
go
by
every
specification
and
see
if
there
are
any
issues
open
or
just
start,
creating
pro
requests
or
go
through
the
platform
to
see
on
the
board
that
there's
something
that
can
be
done?
I
yeah.
B
A
A
B
D
So
it's
basically
indeed
just
go
for
it.
So
it's
as
Steve
mentioned
it's
a
specification,
probably
that
you
should
be
like
I'm
ready
using
in
for
weight.
So
if
you
do
PR
for
specification,
you
know
nothing
about
that.
Let
that's
less
likely
for
you
to
succeed,
but
if
it's
a
specification
the
did
he
use
he,
you
know
exactly
what
you're
doing
or
you
know,
even
how
what
you're
doing
than
just
to
go
for
it.
Indeed,.
C
D
I'll
create
an
issue
first
and
then
like
ask
for
some
feedback,
so,
for
instance,
in
JSF,
the
the
work
for
the
namespace
change
would
be
based
off
of
2.3
and
that's
in
the
separate
branch
and
the
McMaster
is
currently
going
to
be
first
and
then
rebuilt
from
2.3.
If
you
don't
know
that
you
would
do
the
OPR
mom
master,
then
it
couldn't
be
accepted
there
and
that's
with
music
extra
work
for
you.
Indeed,
there's
market
status
handy,
it's
good
to
first,
ask
which
branch,
if
you
do
or
not
somebody
else
is
working
on
it.
Yes,.
D
So
maybe
comments
about
the
JDK
11
item
that
Steve
mentioned.
So
we
briefly
discussed
that
before
and
like
one
of
the
proposals
was
and
there's
been,
no
means
that
it's
going
to
be
accepted
a
final
over
whatever,
but
that's
to
have
to
do
subsets
of
the
specification.
Basically,
so
you
would
have
the
Carta
ie9
for
JDK
8
and
ricotta
ee9
for
JDK
11
and
those
could
potentially
be
two
certifications.
D
D
Yes,
on
the
pan
and
the
if
Jakarta
89
is
just
about
the
namespace
at
least
you
should
perhaps
only
do
the
names,
but,
on
the
other
hand,
Teddy
K
8
is
quite
old,
and
this
is
the
opportunity
to
at
least
move
suit
etiquette.
11
most
platforms
are
all
very
using
the
etiquette
11
anyway.
Most
of
the
offenders
are
meant,
so
it
wouldn't
be
a
really
big
step,
but
it's
something
that
needs
to
be
discussed.
That
time
is
running
out
quickly.
Yes,.
A
D
So
if
you
supported
s
offender
like
we
did
for
pyaara,
then
you
don't
necessarily
have
to
guarantee
that
it
works
or
that
the
t
ck
has
passed
on
it
and
the
the
spring
are
still
in
the
next
point.
There
TCK
would
need
to
be
updated,
at
least
in
some
way,
to
support
verifying
that
it's
virtually
erika
11
could
also
mean
some
work,
which
could
delay
the
release
of
Jakarta
anon.