| Hi Mike.
Sorry for the delay but I was in back-to-back virtual meetings all day Friday. I’m sure by now someone else has pointed this out to you but it’s all in the MP archive which I believe is hosted by the EF so you should have no trouble finding it :)
Mark.
On 2020-04-03 8:05 a.m., Mark Little
wrote:
Yeah we had that conversation in the MP community.
Let's respect that decision even if you don't agree with it. You
know ... good open source practices and all that, right ;) ?
What decision? Can you point to where that happened?
It’s not orthogonal if the
communities were merged. MP could switch all apis to the
jakarta namespace when it adopts Jakarta EE 9 at the
same time as the base specs switch from javax to the
jakarta namespace.
Steve
Sure but that is totally orthogonal
to whether Jakarta EE changes the namespace when it
consumes MP components. What isn't orthogonal is the
potential splitting of community activities across
these forks. I'll be blunt here, I'm less concerned
about the continued viability of the original MP
specifications as I am about the forks into Jakarta
EE.
On the community concerns.
The MicroProfile community is adamant that it is
independent and will evolve with no concern for
consumers of the specifications to maintain
velocity and to remain innovative (the Pull
model). It’s not a position I argued for at the
time within MicroProfile I argued that the
communities should merge and therefore there
would be no community concerns and these
questions would not arise. See
https://blog.payara.fish/microprofile-and-jakarta-ee-technical-alignment
However we are where we are.
Steve
OK let's take the case of
CORBA ... last time I looked Java EE did not
change the namespaces when it incorporated
CORBA and when it took the OTS and renamed
it to the JTS. And OTS wasn't stable at that
time, going through several subsequent
revisions, as did CORBA.
I also note you didn't
address the community concerns I raised.
The log4j example
is spurious. Log4J is a library jar
not a specification. How many people
need to support 2 versions of log4j in
their application?
As a counter
example I have seen many runtimes
shade a popular library jar thereby
changing its namespace for stability
reasons, exactly because an
application may incorporate a
different version to the one shipped
in the runtime.
+1
Also as pointed
out during the MP “push vs pull”
debate was the important fact that
if any group wants to pull an MP
specification then whether or not
they change the namespace is really
independent of stability. I can’t
recall the last time (or first time)
I came across a project which forked
log4j and changed the namespace “for
stability” reasons.
I hope anyone
considering forking any
specification or project considers
the potential implications on
communities. Better to collaborate
and put up with some different
namespaces. Many MP and Java EE
users have been doing that for years
so far without complaint.
Finally, I assume
if a fork goes ahead that there is a
developer community behind the
forked effort tracking MP or it
might go stale quickly, missing
critical updates etc.
>
During the MP technical
discussion there was
discussion about those
things and it was clear for
everyone that the "move
fast and break things" of MP
is a valid scenario but with
consequences for downstream
consumers (they require a
fork if they want
stability)
If
Jakarta wants a stable
version of MP Config, they
can simply pick a version
of MP Config and stay with
that version, right? Say
MP Config 1.4, and since
MP follows semantic
versioning rules, really
Jakarta could work with
any version of MP Config
1.X.
>
MicroProfile did what it
needed to do, now it is
time that Jakarta does
what it needs to do and
move forward. It can't be
blocked because the people
of MP don't think it is a
good idea (and they
shouldn't care about it as
they would not consider
downstream consumers)
But
Jakarta does _not need_ to
do this. Furthermore, if
Jakarta forked+promoted
its own version of Config,
they would not be a simple
downstream consumer of MP
Config. Jakarta would be
essentially creating
something entirely new
(i.e. not binary
compatible) that tries to
fracture the
existing+future
userbase of the Config
API.
We need
to consider who would
benefit from such a fork,
as opposed to Jakarta
simply adopting the MP
Config 1.X spec (which
again, follows semantic
versioning which
guarantees no breaking
changes).
During
the MP technical
discussion there was
discussion about those
things and it was clear
for everyone that
the "move fast and
break things" of MP is a
valid scenario but with
consequences for
downstream consumers
(they require a fork if
they want stability)
MicroProfile
did what it needed to
do, now it is time
that Jakarta does what
it needs to do and
move forward. It can't
be blocked because the
people of MP don't
think it is a good
idea (and they
shouldn't care about
it as they would not
consider downstream
consumers)
I
strongly oppose the
idea of forking MP
Config in Jakarta.
Politics
aside, it is an
absolute headache
from a technical
perspective. It's
going to be the
javax->jakarta
rename all over
again, except
worse because the
"old" spec (MP
Config) will still
move forward on
its own.
Config
needs to be a
foundation
technology that
lots of other
library
implementations
can depend on.
If we have a
Jakarta Config
and a MP Config
API
floating around,
how will those
libraries
support both
APIs? If a
property is set
at the same
ordinal in both
MP Config and
Jakarta config,
which one should
win?
If
the solution of
forking a
Jakarta Config
is only feasible
if MP agrees to
kill of MP
Config, I highly
doubt that will
happen, and
frankly it is a
rude thing to
ask another
community to do.
I
agree that MP
has the freedom
to "move fast
and break
things", but MP
does not break
things just for
fun. In the case
of MP Config, it
is a pretty
stable
technology that
is feature
complete, so I
highly doubt any
new breaking
changes will
arise in the
future. Even if
they did,
Jakarta could
define
which version of
MP Config it was
capable of inter
operating with.
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.
:)
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--- Mark Little mlittle@xxxxxxxxxxJBoss, by Red Hat Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873 Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
|
