[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE 9
|
> I
am always happy to step aside for someone that feels they have better insight
and feel they can do a better job. Please, Steve,
don't step aside! I need you. :-)
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
11/27/2019
14:13Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] VOTE: Specifications to add
inJakartaEE 9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
The
project committers of the Jakarta EE platform are making decisions in good
faith. I think it is unfair to say we are not considering carefully the
pros and cons. We have to move forward and decide what is in Jakarta EE
9 in a timely fashion in order to actually have a Jakarta EE 9 release.
The emails here and the votes are the process whereby we solicit that input.
If
somebody thinks they have a better process and wish to delay the 9thDecember date for a release plan so they can follow some other process
I think they should step forward now and propose that they take this work
on and drive it to a timely conclusion. I am always happy to step aside
for someone that feels they have better insight and feel they can do a
better job.
Steve
From:jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Amelia Eiras
Sent: 27 November 2019 19:52
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>;
erik.brangs@xxxxxx
Subject: Re: [jakartaee-platform-dev] VOTE: Specifications to add inJakartaEE
9
+1
Erik and quote you:
I
think that not providing technologies that were available in Java EE 8
(even if they came from Java SE) is very risky for the future of the project
because it runs contrary to the expectations of backwards compatibility
that might exist. In my opinion, backwards compatibility is essential and
in the special case of Jakarta EE it is not only about what's actually
in the specs but also about the perception of changes by the community.
Stated
on another thread [linked below] , it seems that the current work being
done in Jakarta EE 9 release is not considering carefully the pros &
cons. At this time, we don't have the actual data from users, as an ecosystem,
to sustain current desires of what effectively cut or not. Being
patient while doing the work now seems the wisest step forward instead
of graving into a whole that cannot be fixed later, Trust is lost via small
actions & rarely lost with just 1 action itself. I am wary of what
currently is. I am considering not only the coders but the users
as both are core and important for this project's success.
Current
methods are pushing on the side of radical steps, that is a red flag in
itself for users. Are we really choosing to become that ecosystem?
Erik,
you are one great example of a Jakartee whose arguments are
impossible to ignore.
--
The power-of-preparation, POP, from this community cannot be underestimated
or deferred. We have now.
The
project requires individuals whose arguments are hard to ignore or push
around, those who makes us understand our weakness are the most valuable
contributors. -- Nov
26th forum Community thread
Amelia
Eiras
twitter.com/ameliaeiras
Tribe:http://tomitribe.com https://tribestream.io
OSS: http://microprofile.io https://jakarta.ee
On
Wed, Nov 27, 2019 at 11:32 AM Erik Brangs <erik.brangs@xxxxxx>
wrote:
Hi,
On 27.11.2019 19:21, Werner Keil wrote:
> Well it breaks as soon as they run their Java EE 8 compliant app or
container in a JDK above Java SE 9, so it is not the fault of Java EE or
Jakarta EE in that case.
To me, it does not matter whose fault it is. What matters to me is that
it breaks my expectations. I think that not providing technologies that
were available in Java EE 8 (even if they came from Java SE) is very risky
for the future of the project because it runs contrary to the expectations
of backwards compatibility that might exist. In my opinion, backwards compatibility
is essential and in the special case of Jakarta EE it is not only about
what's actually in the specs but also about the perception of changes by
the community.
> Offering this in a way that allows applications to use it but not
necessarily blow up the Full Jakarta EE stack more (instead of also removing
stuff) Sounds reasonable.
A more comprehensive Full Jakarta EE profile is an asset from my point
of view. The more technologies it contains, the more functionality I can
implement in pure Jakarta EE without having to rely on external libraries.
I'd prefer more profiles with a reduced set (e.g. "Cloud" or
"Opinionated REST") over a smaller full profile. A newer, bigger
profile (e.g. "Everything but the kitchen sink") would also be
fine with me. However, AFAIK Jakarta EE 9 won't contain any new profiles
so what's important for me is what is in the full profile.
Kind regards,
Erik Brangs
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev