| Mike, they are closely related. But let me take this time to explain.
It seems to me that some in the Jakarta EE community and Eclipse Foundation are forgetting one very valuable thing about successful open source efforts, such as MP: they’re not owned by Red Hat, IBM, Tomitribe, EF or others who have contributed so much over the years, or those who have sat outside and watched; they are (or in this case, MP is) a community effort and it’s owned by the community. Any other community, such as Jakarta EEM, has no inalienable right to pass judgement on how another community acts or behaves and somehow decide to swoop in and take it over. I’d be as vehemently against that happening here as I would some other group deciding the try to take control over Jakarta EE or some other project in, say, the ASF. Clearly there are ways to exercise control and influence over a community and they are well defined: get involved, influence from within, gain commit rights and try to direct that way. But trying to do this from the outside it something none of us should be comfortable with doing - that’s not good open source collaboration. Anyone remember Hudson these days?
Speaking very specifically about Jakarta EE and MicroProfile, there is nothing in either community rules of engagement or statement of intent, or whatever we want to call it, that allows one to have expectations on the other. We should treat these two communities as peers and with respect. Even though there is overlap in the community membership that does not mean any of us should assume they are so closely related that what one wants the other must also want or bend towards. I sit in both communities. I’ve helped create both communities. Yet to paraphrase HG Wells, at times in these conversations it’s as if some in Jakarta EE "regarded [the MP community] with envious eyes, and slowly and surely drew their plans against us.” That’s no way for anyone to behave.
There should be no default rule for the relationship between Jakarta EE and MicroProfile because each MicroProfile specification is often driven by a mix of different developers, vendors and communities who may not want their efforts forked. To ignore them is tantamount to a hostile take-over. The Jakarta EE communities should work with them and try to persuade them to see their point of view. However, if the MP spec community cannot be persuaded then I caution continuing with a fork. Embed and try to work together because the MP spec should still be usable within Jakarta EE. And working with the original community is a far better path to future success than trying to split efforts.
If no way to collaborate can be found, including simply embedding that spec into Jakarta EE, then I'd suggest that there is something fundamentally wrong with that specific MP spec community or those in Jakarta EE. I really can't see this ever happening though so it's not worth further consideration: generally everyone is pretty reasonable and friendly in both communities.
Then there's the notion of changing the namespace of a MP specification if it is "imported". Well I also don't think that should be a hard and fast rule either. It should be something that is worked out between the MP specification in question and the Jakarta EE community. If the MP spec community rejects changing namespace then that should also not be a reason to reject importing and collaborating with them and defaulting to a hostile-like fork. Regardless of the potential conflicts that could arise just think of the PR nightmares.
And that brings me to the final question: where does work on the MP specification continue, assuming it does need to continue? Well guess what? I think that's up to the MP spec community since they are the founders of their work and their future destiny. If they feel that innovation should shift entirely to Jakarta EE then go for it, with all of my support. But likewise, if they feel innovation should continue in MP and maybe they are a part of the corresponding Jakarta EE community which then works to pull updates across when it makes sense that’s great collaboration too. Everyone wins and we drive forward together.
Just in case this is lost on anyone who read this far or is skipping to the conclusion, my main point is that whether MP produces specs, TCKs or something else, it is an open source community effort. We should treat it no differently in that regard than we would treat some other open source project with which we want to collaborate and definitely no different to how we would want others to treat us.
Mark.
I followed "push vs pull" very closely.
What does that vote have to do with this purported governance
decision?
On 2020-04-03 9:20 a.m., Ken Finnigan
wrote:
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
-- Mike Milinkovich Executive Director | Eclipse Foundation, Inc. @mmilinkov +1.613.220.3223 (m)
_______________________________________________ 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)
|
