| Re: [rest-dev] [EXTERNAL] Re: EE11 Platform call update |
|
Thanks everyone for engaging in this I deeply appreciate ya’ll’s time and effort. Replies in line. On Wednesday, February 21, 2024 1:27 PM rest-dev
rest-dev-bounces@xxxxxxxxxxx On Behalf Of Markus Karg MK via rest-devsaid: Sent: Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update MK> Speaking just for myself, I need to say that I do have a problem MK> with *removing* JAXB. I have to maintain a software that on one MK> hand shall use latest features, but on the other hand MUST stick MK> with JAXB for backwards compatibility. It is OK for me that JAXB MK> would become *optional* so I can simply drop it into the mix on my MK> own. But *removing* instead of *optional* is a no-go for me and MK> completely WAY off Java's long-term backwards compatibility MK> benefit. Having said that, it is not our charter to necessarily do MK> exactly what the platform people dream of just because they would MK> like so, in particular not *forcefully remove* things just because MK> they want to spare maintenance costs for their paid products or MK> whatever benefit they like to have from *removing* it. HI Markus, I'm glad you brought this up. In my role as release co-coordinator for Jakarta EE 11, I assert that one artifact delivered by the community served by the rest-dev
list is a component spec and ratifying compatible implementation for Jakarta EE 11. For discussion, label this as ASSERT_REST_EE_11. Other artifacts delivered by this community are not of interest to me in that role. Can someone please validate ASSERT_REST_EE_11? MK> Due to that I am -1 for *forcefully removing* JAXB, but I am +1 MK> for having it *optional* in the sense of "application vendors can MK> put it on the classpath if needed". As a side effect, there is not MK> justification for a 4.0. In my role as release co-coordinator for Jakarta EE 11 I want to draw your attention to the decision made in the Jakarta EE specification committee (aka "the platform people
dream of") that predates my accepting the role of release co-coordinator for Jakarta EE 11. On 2023-02-08, the Jakarta EE Specification Committee (not "the platform people") SpecCmte: wrote: SpecCmte> "Draft resolution for optional features in the Platform SpecCmte> specification (also see issue #54), to be put forward for SpecCmte> ballot in the 02/08 call: https://github.com/jakartaee/specification-committee/issues/54 SpecCmte> "An individual specification can have optional features, SpecCmte> however when a component specification is included in the SpecCmte> Platform and Web Profile, and Core Profile an optional SpecCmte> feature must be explicitly declared as required, otherwise SpecCmte> it is not required. This requirement is noted in the SpecCmte> Platform specification.” SpecCmte> The resolution was put forward by Scott Stark and seconded by Tom Watson" SpecCmte> Kenji Kazumura - Fujitsu [+1] SpecCmte> Tom Watson - IBM - Emily Jiang [+1] SpecCmte> Ed Bratt - Oracle - Dmitry Kornilov [+1] SpecCmte> Andrew Pielage - Payara - Petr Aubrecht [+1] SpecCmte> David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez [absent] SpecCmte> Ivar Grimstad - PMC Representative [+1] SpecCmte> Marcelo Ancelmo - Participant Member - Abraham Marin-Perez [0] SpecCmte> Werner Keil - Committer Member [absent] SpecCmte> Scott Stark - Red Hat - Scott Marlow Enterprise Member [+1] SpecCmte> Zhai Luchao - Shandong Cvicse Middleware Co. - Enterprise Member [+1] SpecCmte> 7 +1 / 1 0 / 0 -1 / 2 absent
SpecCmte> This resolution passes Source:
https://docs.google.com/document/d/1e6FNVgcKJfVz4TZ6qSPs4QbcOZvkIdhu6jGwgk7txlw/edit Now, coming back to what Markus said about the charter of this community (of which I am not a member, but I am a Java Champion and have a passionate stake in the success of this
community.) MK> it is not our charter to necessarily do exactly what the platform MK> people dream of just because they would like so, in particular not MK> *forcefully remove* things just because they want to spare MK> maintenance costs for their paid products or whatever benefit they MK> like to have from *removing* it. Where is it documented what is in and not in this charter? On Wednesday, February 21, 2024 1:45 PM rest-dev
rest-dev-bounces@xxxxxxxxxxx On Behalf Of Jim Krueger JK via rest-devsaid: Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update JK> My [wording] was perhaps unfortunate. JAXB itself is not being JK> “removed”. It will still be optional. It just is not part of the JK> platform any longer. Liberty, for example, will still support JK> JAXB with EE11. What we’ve been asked to do is to remove the JK> dependency that Jakarta Rest currently has on JAXB. This will JK> just involve removing the Link.JaxbLink and Link.JaxbAdapter inner JK> classes that were deprecated in Jakarta Rest 3.1. On Wednesday, February 21, 2024 3:25 PM rest-dev
rest-dev-bounces@xxxxxxxxxxx On Behalf Of Arjan Tijms AT via rest-devsaid: Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update AT> I think the major issue is that JAXB cannot be in Jakarta REST, AT> since Jakarta REST is the core HTTP engine in Jakarta EE (in the AT> Core Profile). The core profile does not have JAXB included. This AT> is the same reason that Jakarta _expression_ Language had to be AT> removed from CDI. I believe this is also technically correct. When I imagine sitting down to churn out the
ENTIRELY NON NORMATIVE EE 11 M2 maven artifacts, I am pretty sure this will blow up in my face. AT> Newer products like Quarkus can't support those older things like AT> Jakarta _expression_ Language and JAXB (at least not out of the box, AT> I know there are various third party add-ons that bring it back AT> from the Quarkiverse). AT> Traditional servers like GlassFish, Open Liberty, WildFly etc AT> should have no problems with supplying JAXB, and build-your-own AT> stacks using e.g. Jersey and Tomcat should also not have any AT> problems to continue support for JAXB. On Wednesday, February 21, 2024 5:17 PM rest-dev
rest-dev-bounces@xxxxxxxxxxx On Behalf Of James Perkins JP via rest-devsaid: Subject: [EXTERNAL] Re: [rest-dev] EE11 Platform call update JP> The removal of XML Binding was already done in the release-4.0 JP> branch [1]. I wouldn't think we'd be doing anything beyond JP> removing the module dependency and the Link.JaxbAdatper and JP> Link.JaxbLink [2]. Is this what you mean or do you mean JP> specifically with the specification document removing the optional JP> XML Binding specification? JP> FWIW my understanding is we only want to remove the module JP> dependency and the two deprecated types. From: rest-dev
rest-dev-bounces@xxxxxxxxxxx On Behalf Of Santiago Pericasgeertsen SPG> viOn Thursday, February 22, 2024 11:12 AM est-devsaid: Subject: Re: [rest-dev] [External] : Re: EE11 Platform call update SPG> That’s the only compile-time dependency that I remember, so that SPG> is basically it AFAICT. That is a relief. Thanks Ed Release co-coordinator for Jakarta EE 11 | edburns@xxxxxxxxxxxxx | office: +1 954 727 1095 | Calendar Booking:
https://aka.ms/meetedburns | | Please don't feel obliged to read or reply to this e-mail outside | of your normal working hours. | | Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact |