I don't want to decrease the agility of Jakarta EE, how can we
change the EFSP to accomplish that? Otherwise, how will Jakarta EE
break out of the slow release cycle that Java EE was suffering?
I think you're mistaken about what needs to be done to appease
Oracle.
If the key difference is that MP is "not a standard" and Jakarta EE
is (will be) "a standard", and that's going to make Jakarta EE less
agile and suffer a slow release cycle, well, maybe we don't want
Jakarta EE to be "a standard". Maybe, as you suggest, we should be
satisfied if it just has wide-spread adoption. If that's good
enough for MP, why is that not good enough for Jakarta EE?
Richard Monson-Haefel wrote on 12/20/18
11:37 PM:
Good question. The EFSP process is far more formal
than what MP has now and I believe it would slow down MP's
progress and decrease agility of that effort. You could not
have had as many releases as you have had with MP already if it
was constrained by a formal specification process like the
EFSP. That's not good considering the primary reason MP was
created was to break out of the slow release cycle that Java EE
was suffering.
Jakarta EE has to have a formal spec process to appease
Oracle and the millions of organizations that have relied on
it being a standard. The MP doesn't carry that baggage.
Becoming a standard is not a guarantee of success. Just
look at Spring. No formal standards process acts as an
umbrella to the project yet it's very popular. Or look at
DCE or CORBA, very formal process with lots of
specifications and very little adoption. You could nit-pick
those examples apart, but the general idea is that standards
and wide-spread-adoption are not synonymous.
Why do you not want Jakarta EE to be
independent and agile?
Richard
Monson-Haefel wrote on 12/20/18 2:24 PM:
Mike,
You have alluded to this problem before - that MP
will have to adopt the EFSP - but I don't recall you
providing an explanation. That would probably go a
long way in helping folks like me understand why other
projects suddenly have to adopt the EFSP. I'm all for
it with Jakarta, but MP has been doing fine without a
formal process and I would like to see it remain
independent and agile. Sorry if this gets people's
knickers in a kerfuffle but its a valid point of view
considering how little we know about your position on
the subject.
Richard
On
2018-12-20 11:54 a.m., Richard Monson-Haefel
wrote:
Given that the MP has not planned
to adopt the EFSP, I wonder if Microprofile
should move to a new host? It might be the best
solution for all.
I don't find that to be a very constructive
comment given that you haven't even heard what our
concerns are. And the issues that we are seeing
are not going to go away if it's hosted somewhere
else. Success comes with greater responsibilities.
Plus, as Steve pointed out we already have an
example of a MicroProfile spec entering the JCP
process. So there is already an entirely
community-led precedent to follow.
Perhaps we should down tools on the email and
discuss this in real time in January.
On
2018-12-19 12:36 p.m., Scott Stark wrote:
We should be looking
at elements of the MicroProfile process
that seems to work and attempt to
accommodate the possibility of
MicroProfile using a future EFSP, but I'm
not convinced that it is a requirement,
and potentially not even possible.
Scott, et al,
I guess I was being too subtle in my
previous email on this thread. In our
opinion, simply maintaining the status quo
is not an option. Adoption of the EFSP by
MicroProfile is a question of when, not
if.
The existing specification process and
licensing regime for MicroProfile is
causing the Eclipse Foundation serious
concerns. We do not feel that the status
quo is an acceptable long term scenario.
This is the result of both the success in
the industry that the specifications are
achieving, and what we have learned as an
institution as we created the EFSP.
Happy to explain more details on a call.
![Avast logo]()
|
This email has been checked for viruses
by Avast antivirus software.
www.avast.com
|
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--
|
