Not involved in this resolution, but providing insights I can. On Jun 12, 2025, at 2:53 PM, Will Lyons via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
- The proposal says: "All specifications must use the jakarta namespace". None of the existing Jakarta EE 8 specifications use the jakarta namespace.
What is the implication of the proposal for the existing Jakarta EE 8 specifications? Will they be declared no longer Jakarta EE Specifications? The JESP should not be ambiguous on such questions.
If this JESP version is approved by the Spec Committee and adopted at the Steering Committee level, it would only have requirements on specifications developed after that point. Specifications released under previous JESP/EFSP versions remain valid. Essentially released specifications are tied to the JESP version in effect when they were released and the JESP version is explicitly tied to a specific EFSP version. Changes to the EFSP do not impact current or older JESP versions and changes to the JESP do not impact specifications released under older JESP versions.
- There is an ongoing discussion with the MicroProfile Working Group about contributing MicroProfile specifications to the Jakarta EE Working Group.
Is the implication of this proposal that if another group, such as the MicroProfile Working Group, were to offer to contribute existing MicroProfile Specifications “as is” to the Jakarta EE Working Group, that the Jakarta EE Working group would refuse to accept
them? Does it make sense to impose broad restrictions on such contribution processes that have not been defined or thought through yet?
That would be the implication unless the JESP was updated again, which is always possible.
- I do not understand what the benefit of the proposal is. The proposal does not solve an immediate problem. Has anyone proposed a new Jakarta EE specification
that does not use the jakarta namespace? I don’t think we should change the JESP process without a clear benefit, or to solve spec process problems that do not yet exist.
- There may be cases that we have not considered where use of a “non-Jakarta namespace” in a specification would have some compelling technical or end
user or other benefit, and this resolution appears to preclude future consideration of such options. Let’s not preclude options that we may wish to exercise in the future without a compelling reason to do so.
- I am not directly familiar with all the opinions of all MicroProfile community members, but my guess is that the primary practical impact of adopting
the proposal would be to cause some percent of MicroProfile community members to view Jakarta EE more negatively, and to be more reluctant to contribute MicroProfile specifications to the Jakarta EE Working Group. I think this is a negative outcome.
My read is all but a minority want to move and all but a minority want to use the jakarta namespace. I don't perceive a situation where this would prevent MicroProfile from coming to Jakarta. That feels like a done deal.
My biases are against a move, but in favor of using the jakarta namespace if we do move.
-David
From:
jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of Ivar Grimstad via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Date: Thursday, June 12, 2025 at 3:38 PM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [External] : Re: [jakarta.ee-spec] [BALLOT] Update JESP to Clarify `jakarta` Namespace Requirements
Greetings Jakarta EE Specification Committee.
This is the ballot to action the proposal made in the 11th June Specification Committee meeting to update the text in the JESP to provide clarity on if the 'jakarta'
namespace is required or not.
The proposal is to clarify the Specification Committee stance and add the following text to the JESP: "All specifications must use the jakarta namespace".
Per the process, this will be a seven-day ballot, ending on the 19th of June 2025 that requires a Super-majority positive vote of the Specification Committee
members (note that there is no veto). Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.
The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Tomitribe, Primeton, and
Shandong Cvicse Middleware Co.), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.
Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can
provide to support your vote will be appreciated.
|
|
Andrew
Pielage
Senior Software Engineer
|
|
|
|
|
<C2_signature_web_b74fc64d-c0d9-449d-867e-91eba02c4fa3.png>
|
|
|
|
<C2_signature_phone_da9e4309-497c-4bc2-ba2c-2873a279f95b.png>
|
|
|
Try our fully managed cloud native application runtime. 15 day trial available.
Payara.cloud
|
Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467
|
|
|
|
|
Andrew
Pielage
Senior Software Engineer
|
|
|
|
|
<C2_signature_web_b74fc64d-c0d9-449d-867e-91eba02c4fa3.png>
|
|
|
|
<C2_signature_phone_da9e4309-497c-4bc2-ba2c-2873a279f95b.png>
|
|
|
Try our fully managed cloud native application runtime. 15 day trial available.
Payara.cloud
|
Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467
|
|
|
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
--
Ivar Grimstad Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse
Foundation - Community. Code. Collaboration.
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
