To be
honest, what you are suggesting
is even more worrisome. What it
implies is that there will be
two standardization models in
enterprise Java that are highly
duplicative and basically
competing. That will hardly
reduce the fragmentation,
confusion and divisiveness. That
is why many of us would like to
see Jakarta become the unifying
standardization model.
I would
say this is all the more reason
to fork and standardize right
now.
Reza
Rahman
Jakarta
EE Ambassador, Author, Speaker,
Blogger
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/6/20 10:40
AM (GMT-05:00)
Subject: Re:
[jakarta.ee-community] Fork
Eclipse MicroProfile
Configuration
as Jakarta Configuration.
First of MP is in the process of
transitioning to the same
standards
model as Jakarta, so it seems a
little backhanded to ignore that.
So
further standardization is some
form of duplication of
standardization. Simply because
other Jakarta members are not
clear
that a fork is the best way to
incorporate MP specs into Jakarta
does
not mean we might eventually
settle down to that. There were
discussions about employing an LTS
model in MP, transitioning specs
to
mature vs innovating, etc. in the
pull thread discussion. Eventually
those will have to be compared
against a simple fork, but this is
an
EE10 timeframe discussion that is
not a priority for me right now.
On Mon, Apr 6, 2020 at 6:41 AM
reza_rahman <
reza_rahman@xxxxxxxxx>
wrote:
>
> I very much empathize with
folks like Anthony as we are
essentially in the same boat. One
of the most frustrating aspects of
MicroProfile is the radically
changing goals that does not seem
terribly consistent or entirely
rational.
>
> My expectation has always
been and remains that MicroProfile
features that are mature enough
will be properly standardized into
Java/Jakarta EE - quite possibly
into a new profile targeted for
microservices. In no way do I see
this diminishing the value of
MicroProfile. Indeed historically
standardizing features from any
source typically enhances the
value and usage for both the
source and the open standard. I
also can't think of any example of
something being standardized
"as-is" out of something that
itself is not an open standard. I
really have a hard time
understanding why any of what
Otavio is proposing is radical in
any way from a rational, technical
standpoint.
>
> With regards to the premature
standadization viewpoint, it would
be helpful to understand precisely
what the short term roadmap is and
why that work would not be
appropriate to do within an open
standard effort instead of an open
source project that isn't an open
standard and probably should never
aim to be due to it's explicit
focus on innovation.
>
> Are there other unstated
factors at play behind the
objections to further
standardization? If so, why not
state them explicitly so they can
be evaluated and discussed?
>
> Reza Rahman
> Jakarta EE Ambassador,
Author, Blogger, Speaker
>
_______________________________________________
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
To unsubscribe from this list, visit