I don't have the exact URL here but if you check the thread you'll find it. There are at least 3 historical committers including the likes of Arjan who may simply have a lot on his plate, not sure if he stopped for another reason.
Arjan does regularly comment on issues related to Jakarta REST. You can check the archives.
You or your or predecessor should know the case where at least one former EG member from Red Hat at the time resigned over a dispute or something.
That was way before Jakarta, your stated " high fluctuation even now under Eclipse/EE4J/Jakarta EE”.
MVC has a couple of issues, also regarding its possible inclusion in Jakarta EE. I heard several first hand by its Spec Lead Ivar who did not exaggerate kindly calling me "The JCP guy" yesterday at CodeOne ;-)
I don’t know how this relates to your previous statement about JAX-RS and MVC.
The duplicate spec at Microprofile for Rest Client was seemingly overlooked, but maybe as project lead you know best, if it would be good to contribute those things back to Jakarta Rest or they do something not worth standardizing.
It was not overlooked. The notion of a declarative client API was discussed as part of the JAX-RS 2.0 spec many years back and before MP started (I’m sure that’s archived somewhere), and not everyone was in agreement to include such an API despite it already being supported by some vendors. In this regard, there’s absolutely nothing wrong for other specs to build on top of JAX-RS, not everything needs to be part of the core.
— Santiago
Last but not least Microprofile spawned off a REST Client Spec that at least partly competes with Jakarta REST outside Jakarta EE which adds even more confusion and places people have to look if they write an app that uses both.
Writing any MP application would require looking in multiple places. MP’s foundation is CDI, JAX-RS, JSON-[BP], an these specs exist there only by reference. To be clear, the MP REST Client spec (like OpenAPI) builds on top of JAX-RS and provides a declarative approach to building clients (and no support at all for building actual services).
Thus, I don’t think compete is the correct verb here. There is an overlap, yes, in that JAX-RS provides a non-declarative approach for clients as well, but the two can co-exist perfectly fine, with developers choosing their preferred flavor.
FYI, the idea of aligning these efforts has been discussed [1].
— Santiago
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
