I don’t like
the idea of
Jakarta
consuming
“raw” MP specs
for a number
of reasons
If I want to
support the
latest MP and
the latest
Jakarta EE in
the same
product then
it will be a
nightmare, if
they run at
different pace
but are in the
same
namespace.
This will
drive us to
shipping
separate
products and
therefore
Jakarta EE
developers
will be
excluded from
the latest
innovations in
MP.
Jakarta needs
to be a
consistent
platform, it
has enough
problems with
multiple bean
models that
need unifying.
Therefore
changes may
need to done
to
specifications
to make them
consistent
with the
current state
of the overall
Jakarta EE
platform and
to make them
work well in
the context of
Jakarta EE.
Given the MP
stated goal is
to be not
concerned with
how consumers
use the
specifications
I assume this
work will need
to be done
within the
Jakarta
efforts.
MP goal is
rapid
innovation,
“move fast,
break things”
Jakarta’s goal
is a stable
evolving
platform with
backwards
compatibility
requirements.
These things
are
inconsistent.
If a developer
is using the
MP namespace
then they know
apis may
change. If
they are using
Jakarta apis
then they have
backwards
compatibility
guarantees.
Mixing the
namespace
within the
Jakarta EE
platform
breaks that
understanding.
Finally for
politics. IMHO
many members
of the MP
project do not
really see
themselves
delivering
standardised
apis in a
multi-vendor
collaboration,
it’s all
about
innovation and
speed. They
balk at
governance,
committees,
etc. and wish
to move
forward like
an Apache
project. MP
should forget
about
specifications,
working groups
etc. and leave
Jakarta EE to
standardize
the innovative
apis where
appropriate
into a
coherent
platform in
the Jakarta
namespace.
The ideal
solution is
for Jakarta to
see MP as a
pool of
innovation for
ideas which we
can adopt,
standardise
and
incorporate in
a consistent
manner into
the overall
Jakarta EE
platform.
Steve
Personally, I
don't like the
idea of
forking, which
might sound
like a good
idea at a
first glance.
However, once
there is a
fork, this
will give end
uers a lot of
headache. When
they do an
import,
multiple
things pop up
and they might
end up use
partial APIs
from either
spec. The MP
Config and
Jakarta Config
spec will go
out of sync
very soon. In
short, there
should not be
2 config
specs.
Having that
said, as
mentioned by
Kevin, MP is
focusing on
creating WG.
Once it is
done, there
are no IP
concerns. Why
can't Jakarta
EE consume MP
Config freely.
Also, I
suggested a
LTS solution
for MP Specs
to indicate
some releases
to be consumed
by Jakarta
etc.
Yes, forking
the MP config
is a good idea
now that
MicroProfile
has decided on
the pull
option.
The Working
Group
discussion
(and thus IP
handling)
doesn't solve
the issue with
the backward
compatibility
which
explicitly
will not be of
any concern to
MicroProfile.
MP Config will
perform a
breaking
change in the
next month, so
even if it
seems stable,
it can't be
referenced by
Jakarta.
Besides the
integration of
MP JWT Auth as
Arjan
proposes, I
also propose
to include MP
Rest client
into Jakarta
REST. We need
to implement
the same
features in
the
respectively
Jakarta
specifications
so it will be
a fork.
When the main
MicroProfile
specs are
forked into
Jakarta, there
will be no
need anymore
to combine the
Jakarta and
the
MicroProfile
specifications
into the
applications
servers and we
will have
Jakarta
runtimes and
MicroProfile
runtimes each
consumes their
respective
specifications.
Yes,
there is
another
option...
Wait a month
or so while
MicroProfile
figures out a
Working Group
proposal. The
MP community
and the EF are
both in favor
of
establishing a
separate MP
Working Group
as a first
step. Once
this is
established,
then the
Specifications
(and APIs and
TCKs) will all
be properly
covered from
an IP
standpoint and
they could be
consumable by
Jakarta EE
projects.
Right. And
specifically
we don't just
need the
Working Group
in place with
a
specification
process, but
we need to
actually do a
release of
MicroProfile
Config under
that process.
We're a few
months away
from having IP
clean enough
for any
proposal on
the Jakarta
side to move
forward.
In short, our
current
status: eat
your meat so
you can have
your pudding.
:)