I'm not convinced that we can't have a formal standardization
process that is also agile. What agile thing do you want to be able
to do that the EFSP won't allow you to do? Let's make a list of the
places where the EFSP inhibits agility and see if we can fix them.
If MP was just an example of code first experimentation in one
implementation, that wouldn't conflict with the EFSP at all. And as
suggested previously, we can always add an "incubating" category to
EE4J projects and/or Jakarta EE specifications to allow whatever
kind and rate of change you think is needed for MP.
But once you have an MP specification, multiple MP implementations,
and an MP compatibility test suite, in what important way is it not
"a standard"? Let's figure out how MP can have all those same
attributes as Jakarta EE and yet remain agile, and then let's fix
the EFSP to allow that.
MP and Jakarta EE are targeting the same developers, there's no
reason they should be competing "standards".
Mike can explain the Eclipse Foundation's concerns with MP, but in
my mind that's completely independent of whether MP should
be part of Jakarta EE. There's nothing MP is doing that we don't
want as part of Jakarta EE.
Richard Monson-Haefel wrote on 1/3/19
4:05 AM:
Jakarta EE will probably never be as agile as MP, because
it has a formal standardization process. You can't have
your cake and eat it too. You can't be agile and have a formal
standardization process.
We can certainly be faster than the old system because we
don't have a proprietary organization delaying or
derailing standardization efforts. Oracle stopped advancing
Java EE because it had different market goals. That's fair.
They can choose to do whatever they want. With Jakarta EE,
there will be less influenced by a single vendor. Java EE has
been a standard for nearly 20 years and changing that now even
with a name change would undermine confidence in the platform
(IMO).
MP, on the other hand, is new and has been running as an
agile process since its beginning. Why change that? My
question is: Why is it so essential that MP adhere to the
EFSP? Why is that required? The only one that can answer
that, as far as I know, is Mike Mlinkovich who I've CCed on
this email.
Richard
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
--
--
|
