Well Core Profile is not a parent of Jakarta EE it is a profile within Jakarta EE and could be a separate project to this one. Which I think is a good option.
As MicroProfile WG is separate to Jakarta EE I think it’s future is a decision for that Working Group rather than the Jakarta EE platform project ;-)
Steve
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of arjan tijms
Sent: 08 December 2022 19:01
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Core profile as its own top level org
Hi,
On Thursday, December 8, 2022, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
Well Payara has a full set of independent implementations of MicroProfile specifications so SmallRye is not the one and only implementation.
Obviously, I even implemented one of those for Payara ;)
It’s just that the current status quo of MicroProfile is a bit murky IMHO. There's hierarchically speaking the core profile that's a parent of both MP and EE, but still we don't want it to be really a parent project
I guess.
Then there's the idea that MP is the modern replacement of Java EE; code first, innovative, fast moving, and with equal representation by many vendors. But in practice that's not really the case either, is it?
MP relatively quickly absorbed the APIs that were already planned for the ill-fated Java EE 7 Cloud theme, and then again proposed for Java EE 8 just before it all went down. But since then innovation has slowed
down considerably. With Jakarta EE now fully transferred, there's no need anymore for a modern replacement of Java EE, and there's also no need to have a separate WG in order to be code first, innovative, fast moving and having equal representation
by many vendors. Jakarta EE has all that too.
Perhaps MicroProfile needs to revert back to an open source project external to the Eclipse Foundation
What do you mean exactly by that? You mean giving up the API/multiple-vendor split, and just move everything to Red Hat/Quarkus? E.g. making Small Rye the one and only implementation?
Maybe that would not be such a bad idea at all. SmallRye would then essentially be a set of Jakarta EE extension libraries like e.g. DeltaSpike, OmniFaces, PrimeFaces, etc. Maybe this is also more in-line with the reality of how things have progressed as well.
This is generally the feedback we get from customers, old and new to the space. Truth be told, the Jakarta EE/MicroProfile segmentation is already cause for a lot of confusion. Core Profile is an obvious need in evolving the space. There is also no harm in
having faster Core Profile only releases and independent specification releases. It’s best to not further segment unless there is truly a compelling need (which I currently honestly do not see). If anything, a path towards gradual brand convergence would be
best (though that is clearly not pragmatic right now).
I understand some folks believe Jakarta EE has a brand perception issue. I tend to think it’s an issue that can be mitigated through consistent delivery, jettisoning truly damaged brands like EJB, serious innovation in implementations beyond the specifications
as well as persistent, high quality marketing/advocacy.
At any rate, my main point is that maybe we should focus on delivering more high quality releases right now instead of more restructuring/reshuffling/renaming/regrouping that’s likely to get in the way of delivery and add to an already very confusing landscape
that maybe actually helps no one.
To an outsider and an end user all this sounds very confusing. Too much of everything usually makes management harder.
Perhaps it is better not to mix MP and Jakarta. Keep MP what it is, an independent(aside APIs of course) extension to Jakarta.
I would say another Working Group is a bad idea as it is another load of bureaucracy, charter, committee and fees. A separate project under Jakarta EE makes more sense to me i.e. splitting the current platform project.
I really like the idea of a separate entity/working group for core profile.
That would also solve the ambiguity around CDI lite that exists today, and a separation of the CDI specs which is really needed. Since CDI lite is not a separate spec, nor has a separate API (which means you have one API where some classes/methods that don't
need to be supported in the runtime) which will lead to confusion, exceptions during runtime (since methods might not be implemented), etc ...
I means we can also remove _expression_ language from the profile since that is only required for CDI full (not supported for CDI lite)
Hi,
Sorry I missed the call today, but that diagram/idea for Core Profile would sound about right leaving aside the Core Profile now includes „CDI Light“.
Kind Regards,
Werner Keil
Hi,
During the platform call we very briefly touched on the core profile being the intersection between Jakarta EE and MicroProfile, but since it's part of Jakarta EE that relation is somewhat unclear.
We had on the table at one point a discussion of making "core profile" (we didn't have the name back then) its own top level working group (org/entity):
Maybe we can revisit this idea again.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
