I agree with your points. I was under the impression that the goal of MicroProfile was to get Java EE moving again and specifically address microservices and cloud shortcomings in the platform. Currently, my impression is that MicroProfile is antagonistic towards Jakarta EE when I was expecting the two would merge together. I thought that MicroProfile were the people who banded together to get things done when Oracle was the obstacle.
With these discussions, MicroProfile is looking less attractive because of the apparent emphasis on breaking things over stability (at least in discussions). There needs to be balance here so that an application can make money before it needs to be updated. The argument that MicroProfile is more agile than Jakarta EE is a bit confusing, I thought that was part of the reason for moving Java EE to Eclipse and changes the processes so that Java EE would be more agile.
With governance of MP, I am not sure if the “pull” vote means that issue has been decided. If that decision is binding (like Brexit), then I think Jakarta EE will need to move forward.
I always looked at Jakarta EE as a standard. Once everyone more or less agrees on a way of doing things.
Separate note, I am shocked at the number of emails on this subject. I wonder if more lines of emails have been spilled on this subject than code written in MP Config =) -Ryan
So we wouldn’t have to throw the towel in and switch to Spring.
As an end user, I'm looking for a comprehensive, consistent,
integrated platform, composed of specifications & with an
overarching platform spec. That's what Java EE has always offered,
and Jakarta EE should do whatever necessary to maintain that. And
yes, even just seeing multiple package namespaces in the Javadoc
wouldn't make sense to me & break the idea of a consistent,
integrated platform.
As an observer, I've been following the evolution of MicroProfile
with increasing astonishment: of the 4 goals in the initial
proposal's scope [1], it seems to me that 3 of them have already
turned into non-goals by now. When Java EE was donated to the
Eclipse Foundation, I was looking forward to the synergy between
MicroProfile & Jakarta EE, exactly because I assumed the
initial goals of MicroProfile still held true, and mature specs
would be migrated to Jakarta EE etc.
I'd very much like to see Jakarta EE move forward, so I'm fully
with Rudy, Reza (who always does an impressive job at voicing the
community's (or at least my) concerns eloquently), Steve, Ondro et
al. here.
Kind regards
Anthony
[1] https://projects.eclipse.org/proposals/eclipse-microprofile
On 05/04/2020 11:55, Ondro Mihályi
wrote:
It's not need to search through the history, the
Pull statement that was selected in the vote mentions enough.
For reference, I added full Pull text at the end of my email.
It literally says that JakartaEE would need to manage
conpatibility and namespce among others, and that's what
Otavio's suggestion addresses. It also says it's up to
JakartaEE to resynch with changes in MP, which can only be
done with a fork in case MP introduces an incompatible change
which isn't acceptable for JEE.
I voted for the pull mechanism only because I
saw that any other solution would cause neverending disputes
and I expected that JakartaEE would be free to choose what to
do with MP specs. And now I see that many people who also
voted for Pull are against JEE considering a fork and are
introducing new disputes. I'm frankly sad about that. We
should explore what's possible and makes sense and choose the
best option for JEE without any prejudices.
For reference, the full MicroProfile Pull
statement:
MicroProfile creates and evolves specifications without regard to downstream consumer requirements (e.g. Jakarta). For example, specification consumers will have to manage items like lifecycle, compatibility requirements, namespace, whether org.eclipse.microprofile is a suitable root package, etc.
MicroProfile can continue to evolve a specification regardless of downstream spec consumers, and it is up to the downstream consumer to decide if it wants to re-sync (or pull ideas from) MicroProfile updates. Additionally, MicroProfile can optionally decide to consume concepts or APIs from downstream projects.
If this is an accurate perception of what
happened it is honestly troubling and goes back again to
that question of good faith in intent, words and
actions.
Can you point to anything that still
exists clarifying a known, intentional expectation of a
fork as a result of the pull vote? I would certainly
like to see it for myself. I tried to follow as closely
as I could but it is entirely possible I missed some
things. Maybe it was in yet another lengthy hangout
recording for which minutes never seem to be shared?
Reza Rahman
Jakarta EE Ambassador, Author, Blogger,
Speaker
Please note views expressed here are my
own as an individual community member and do not reflect
the views of my employer.
Sent
via the Samsung Galaxy S7, an AT&T 4G LTE
smartphone
-------- Original message --------
Date: 4/5/20 3:46 AM (GMT-05:00)
Subject: Re: [jakarta.ee-community] Fork Eclipse
MicroProfile Configuration as Jakarta Configuration.
Can everyone who voted for PULL, stop
complaining against the Jakarta people for exactly doing
what you have voted for.
The word fork was removed last minute from
the pull text but it was always part of it during the
discussions during months and the intention. But this
downstream project is exactly doing what is in the
PULL text, defining the lifecycle, compatibility
requirements and namespace.
And don't start about having 2 different hats.
There is only 1 world, 1 reality in which Jakarta does
exactly what is needs to do based on the outcome of
the PULL vs PUSH vote.
The fork is the only viable solution if vendors
want to keep combining Jakarta EE and MicroProfile in
one product when some of the MP specs are used by
Jakarta Specs.
You are simply
factually wrong in this regard. You're defining
"caring about compatibility" as being synonymous with
"forcing strict
compatibility rules", when this is not true in any
respect.
I voted "Pull" because the chief goal of MP ought to
be to meet user
needs effectively and quickly, even if that means (in
the worst case)
bumpy compatibility at first. As I said,
compatibility is a quality
measure (just one of many) and it arises from a good
specification.
Making a specification be compatible doesn't make it
good or useful.
It's far better to add compatibility restrictions
*after* the
specification is already stable, rather than to add
such restrictions
to a specification that is still rapidly developing
(thereby greatly
diminishing its usefulness in the name of stamping a
logo on it in the
short term). This is (IMO) a good indicator of when
it makes sense to
"graduate" a spec into Jakarta. The consumers of
Jakarta are looking
for long term stability, and that comes from quality,
not from a
compatibility contract.
Voting "Push" would have done nothing to improve the
quality of
specifications and would have obstructed the process
of cross-vendor
standardization - an already inherently politically
and socially
obstructive process. It was a very cynical option
IMO.
On Fri, Apr 3, 2020 at 12:55 PM Werner Keil <werner.keil@xxxxxxxxx>
wrote:
>
> Everyone who voted for this "Pull" option voted
against compatibility and supporting it, not sure how
many votes Red Hat got there and who was eligible but
the majority voted for the "I don't care about
compatibility" option, did you vote for "Push"?
>
>
>
> On Fri, Apr 3, 2020 at 7:33 PM David Lloyd <david.lloyd@xxxxxxxxxx>
wrote:
>>
>> AFAICT the only people claiming that MP
doesn't care about
>> compatibility are MP detractors. MP doesn't
*prioritize*
>> compatibility, but I for one *care* about it
quite a lot. When your
>> first priority is meeting use cases, then
compatibility becomes a
>> quality measure: the easier it is to retain
compatibility in the face
>> of new use cases, the more likely it is that
the specification is
>> already useful for use cases beyond those
originally imagined. The
>> more useful a specification is, the wider its
adoption.
>>
>> On Fri, Apr 3, 2020 at 12:18 PM Werner Keil
<werner.keil@xxxxxxxxx>
wrote:
>> >
>> > And especially one claiming it doesn't
care about compatibility or the consumers of its
frameworks or APIs while the other by definition has
to.
>> >
>> > Werner
>> >
>> >
>> >
>> >
>> >
>> > On Fri, Apr 3, 2020 at 7:11 PM Steve
Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
wrote:
>> >>
>> >> Hi David,
>> >>
>> >> I agree nobody wants to duplicate
effort. Which is why it is non-sensical to have two
separate specification bodies defining specifications
which are intertwined as these discussions on both
sides demonstrate.
>> >>
>> >> Steve
>> >>
>> >> -----Original Message-----
>> >> From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of David Lloyd
>> >> Sent: 03 April 2020 16:49
>> >> To: Jakarta EE community discussions
<jakarta.ee-community@xxxxxxxxxxx>
>> >> Subject: Re: [jakarta.ee-community]
Fork Eclipse MicroProfile Configuration as Jakarta
Configuration.
>> >>
>> >> On Fri, Apr 3, 2020 at 9:56 AM
Werner Keil <werner.keil@xxxxxxxxx>
wrote:
>> >> >
>> >> > All of these are defined by
standard bodies with strong compatibility requirements
like W3C or the JCP.
>> >> >
>> >> > The namespace is not so much a
problem as the "Not My Problem" attitude the MP
stakeholders expressed in their vote for the option
called "Pull". That is even a stronger argument
against using a feature like MP Config as is instead
of a "fork" or writing something heavily inspired by
it from scratch in Jakarta EE.
>> >>
>> >> Who would do the work? We're
rapidly innovating in MP Config right now, learning a
lot about the problem space and processing real user
feedback, and applying that knowledge in a way that
can be consumed today. If you fork, you're going to
end up with probably a separate body of people (where
will these people come from?), developing a separate
piece of software from scratch which, instead of being
based on working and useful implementations, is
top-down designed and has no initial implementations -
discarding that learning process just to spite MP out
of impatience AFAICT. It seems silly to me.
>> >>
>> >> If the bar for Jakarta EE is
stability, you can't clear that bar by crapping out
some code and calling it "stable", no matter how
brilliant you are. It has to be proven in the
laboratory of the real world - an iterative process.
MP Config is going through that process right now, in
fact, and rapid innovation is the direct result of
that.
>> >> We're not breaking things for fun,
and in fact we put forth some effort to not break
things anyway (despite being allowed to). Perhaps
there will be a time where most people are mostly
happy with it and few new use cases arise, rendering
the specification mostly quiescent, but until that
time, anything you do to call the field of
standardized configuration in Java "stable" will
effectively be a lie, just to check a box. Such lies
do little to enhance the reputation of specification
bodies which perpetuate them.
>> >>
>> >> > Not giving a damn about
compatibility requirements means, Jakarta EE probably
would have to fork the TCK for such MP feature anyway
because if the project suddenly decides to run the TCK
with Spock or JUnit 5 instead of TestNG while the
Jakarta EE platform has other foundations of its TCKs,
then Jakarta EE might as well just fork the whole of
it instead of bothering with a TCK fork or trying to
integrate it somehow without support by the authors.
>> >>
>> >> I guess it depends on how much you
enjoy doing busy work. I for one really dislike doing
it; any time spent working on a (possibly
>> >> inferior) parallel specification to
one that is in wide use is time wasted, to me; I can
only imagine that my co-collaborators on MP Config
feel similarly. Who would be left to work on the
specification when all of the experienced engineers
don't want to do it? What kind of specification would
that be?
>> >>
>> >> It's far more rational to let MP
Config continue to do the "dirty work" of figuring out
what works and what doesn't work, and then revisit the
question at a more appropriate time. Consuming MP
Config could be a far more attractive option in, say,
12-18 months time.
>> >> Moving it wholesale to Jakarta might
similarly be a more reasonable option at that time.
It's better than spending 12-18 months arguing over a
new specification anyway - how tiresome that would be.
>> >> --
>> >> - DML
>> >>
>> >>
_______________________________________________
>> >> 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
>> >
>> >
_______________________________________________
>> > jakarta.ee-community mailing list
>> > jakarta.ee-community@xxxxxxxxxxx
>> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>>
>>
>>
>> --
>> - DML
>>
>>
_______________________________________________
>> 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
--
- DML
_______________________________________________
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
_______________________________________________
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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
