| Mike, it doesn’t sound harsh but then perhaps my response will: yes, I read the proposal because I voted on it. However, the interpretation of fork (which I did try to remove BTW) was different to what I believe many here are considering. It wasn’t that some arbitrary group of people or communities would swoop in and take a cut of any spec the liked/were interested in. It was that the original spec developers would do that work themselves when they believed the time was right. There’s an important difference there, which I hope you understand. In going down the latter route it’s not a hostile fork but a collaborative “embed” as I said in my email. And then we come to the namespace which is related but can probably be ignored for now because if you can’t see the difference between these two approaches, both of which are in line with the MP pull model, I think most/all hope is lost.
Now to your point about vendor neutrality. Hmmm, I find that interesting given that there are a lot of other vendors and individuals working collaboratively on this effort today than ever before and have done so since 2016 when you personally were very happy to have MP donated to EF when there was no sign of a Jakarta EE. This concern has been thrown at MP before and I always come back to the same thing: it is disingenuous to those other participants to suggest their efforts are not important or less so than some others. Now I’d have hoped that a vendor neutral foundation such as the Eclipse Foundation would be happy to have such a vibrant and engaging community.
Mark.
Mark,
This is probably going to sound harsh,
but I swear it is an honest question: have you actually read the "pull"
resolution that the MicroProfile community decided on? It
was MicroProfile that decided that it "...creates and evolves
specifications without regard to downstream consumer requirements
(e.g. Jakarta) ..." and that "Downstream consumers will probably
require a fork (with changing package names) to meet the
downstream projects requirements."
It seems that MicroProfile unilaterally
decided the rules of the game, and is now upset that the very
community (Jakarta EE) specifically called out in those rules is
proposing to do exactly what it was told to do.
I hypothesize that some of the emotion
shown in this conversation is a direct result of people
questioning the motives of the Jakarta EE folks when they are
simply trying to implement exactly what the MP community required
them to do. Given that Otavio's proposal obviously complies with
MP's own stated rules, I don't see how anyone is acting in poor
faith here.
Since you were kind enough to advise me
on how open source and communities operate, I would like to in
turn remind you that MicroProfile does not actually produce open
source software. It produces specifications. And in the world of
specification writing, vendor neutrality is vital. It has become
obvious that MicroProfile has a vendor neutrality problem that
needs to be addressed. Hopefully the soon-to-be-proposed working
group governance will fix that.
On 2020-04-06 7:15 a.m., Mark Little
wrote:
Steve, whether you want to sugarcoat it or not,
it's still a fork versus just embedding what's already there.
Work with the relevant MP spec communities and come to a
resolution with which both can live.
Mark.
We are not talking about
forking a project in the traditional sense we are
talking about creating a Jakarta EE specification
based on an open source project and how to incorporate
that into the wider platform in a coherent and
consistent way.
Ondro,
you're definitely not understanding the points I'm
trying to make because I'm not suggesting MP does
anything different to what it has done so far. I am
suggesting that the Jakarta EE community should not
fork MP as if to do so is somehow different to forking
any open source project. Put another way, if you
disagreed with the direction Tomcat was heading would
you fork it? I really hope not. The correct way for
open source projects to collaborate is just that ...
collaborate. Get involved. Earn commit rights.
Influence from within. But do not fork and try to
split the communities. That doesn't usually end well.
Hi
Mark,
I
really don't understand your point in this long
email. This is a JakartaEE mailing list and
nobody from the Jakarta community is suggesting
MP to do anything. We're just discussing how to
cope with the Pull decision of the MP project
and it's MP committers who are trying to dictate
what to do or not to do.
I
would refrain from the criticisng language you
used and rather ask you to suggest how the JEE
and MP community can better understand each
other and find the best way to collaborate.
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.
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@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)
|
