|
fyi - the response from Alasdair (his email was bounced back as he is not part of the Jakarta Spec Committee). By the way, I share his view on this.
Thanks
Emily
================
Emily Jiang
Java Champion, Fellow of BCS
STSM, Jakarta and MicroProfile Architect @IBM
Liberty Cloud Native Architect & Advocate
LinkedIn: https://www.linkedin.com/in/emilyfhjiang/
From: jakarta.ee-steering <jakarta.ee-steering-bounces@xxxxxxxxxxx> on behalf of Alasdair Nottingham via jakarta.ee-steering <jakarta.ee-steering@xxxxxxxxxxx>
Sent: 17 January 2024 14:35
To: Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>; Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: Alasdair Nottingham <alasdair@xxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-steering] Follow up actions from 2024-01-10 regarding Java SE level for EE 11
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Will,
I disagree that the section in the Eclipse Foundation Specification Process relating to Scope Change is applicable here. I believe a change to the scope change would be changing Jakarta REST
to provide APIs for non-REST based web services which isn’t the case here.
The release of Jakarta EE 11 was not defined by creating a Jakarta EE 11 Spec Project and the vote in August was for the Plan Review, not the creation of a new project. If we had created
a Jakarta EE 11 Spec project I would expect to see evidence for it on the Jakarta EE website, or on the eclipse project website, but they indicate that Jakarta EE 11 is a new release from the Jakarta EE 11 Platform project. As evidence for this I point you
at the jakarta.ee website which lists a single Jakarta EE Platform with multiple and to
eclipse project page which reflects the same.
As a result I do not agree with the Oracle position that it is appropriate to have a vote on a scope change.
Alasdair
Alasdair Nottingham
Open Liberty Lead Architect
WebSphere Chief Architect
E-mail: alasdair@xxxxxxx
Mastodon: @nottycode@mastodon.online
Twitter: @nottycode
Time Zone: US
Eastern
From:
jakarta.ee-steering <jakarta.ee-steering-bounces@xxxxxxxxxxx> on behalf of Will Lyons via jakarta.ee-steering <jakarta.ee-steering@xxxxxxxxxxx>
Date: Tuesday, January 16, 2024 at 6:57 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>, Jakarta EE Steering Committee <jakarta.ee-steering@xxxxxxxxxxx>
Cc: Will Lyons <will.lyons@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-steering] Follow up actions from 2024-01-10 regarding Java SE level for EE 11
Ed/Arjan – Thank you for the thorough mail and ongoing coordination of this release. Spec Committee (and ccing Steering Committee members) – Steve Millidge commented at today’s Steering
Committee meeting that this is a significant change in
This Message Is From an External Sender
This message came from outside your organization.
Ed/Arjan –
Thank you for the thorough mail and ongoing coordination of this release.
Spec Committee (and ccing Steering Committee members) –
Steve Millidge commented at today’s Steering Committee meeting that this is a significant change in plan and that no vote was
taken on this change. Leaving aside the actual merits of this change in plan, I believe his concern that the JESP should be followed is valid. During the Steering Committee meeting I said I would review the JESP to assess whether I believed that the process
has been followed.
See below for my detailed assessment[1] but in summary I believe that, without a vote, the JESP process has not/is not being followed properly, and Oracle feels strongly that it should be
followed properly. The change in minimum Java SE version support represents a significant change to the scope of the Jakarta EE 11 Spec Project(s), and under those circumstances a super-majority of the Spec Committee must approve the change in Scope, and
that implies to me a vote where the super-majority is recorded, probably in the form of a ballot. I think it would be sufficient to have a single ballot for Jakarta EE 11 overall (e.g. a Platform Spec change) vs one for each spec, but I believe a recorded
vote with a super-majority approval is required.
I request that the Spec Committee hold a recorded vote to approve this change. If it is required that a Spec Committee member make such a request, I will discuss that with Ed Bratt.
Thanks
Will
[1]Detailed assessment:
- Specification Projects operate under the supervision of both the Project Leadership Chain and their Working Group’s Specification Committee.
- At the time of creation, a Specification Project must provide a well-defined Scope that is bounded by the Scope of its Top-Level Project. Since a change in Scope may change the
nature of the project, a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee.
- A new Specification Project may be created via Project Proposal and Creation Review; alternatively, an existing Project may be converted into a Specification Project via Restructuring Review.
- Here is what I observe for the Jakarta EE 11 Platform Spec (for example):
- This link above says “Minimum Java SE Version Java SE 21 or higher”.
- I am not aware of any subsequent ballots on the Platform Spec.
- AFAICT, the Jakarta EE 11 Platform Spec Project was created as a result of the August ballot which specifically targeted “Minimum Java SE Version Java SE 21 or higher”.
- Java SE 21 or higher is the only bolded item on the page above, and this reflects the focus placed on Java SE 21 in release conception. Based on the importance of Java SE 21 support at the time of Project Creation, and the work impact of adding another Java SE version, I consider adding support for another
Java SE version to be a material change in “Scope” to the Project.
- The JESP/EFSP says “a change to a Specification Project’s Scope must be approved by a Super-majority of the Specification Committee”. The use of the term “Super-Majority” implies
to me that a vote must be taken on the change, with the super-majority verified.
- Such a vote has not occurred. Therefore my interpretation is that the change to the Scope of the Jakarta EE 11 Platform Spec Project is not properly following the JESP/EFSP.
- I recommend/request that a Spec Committee vote be held, and if the super-majority is achieved to change Scope, that the super-majority be recorded.
From:
jakarta.ee-spec.committee <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Ed Burns via jakarta.ee-spec.committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: Tuesday, January 16, 2024 at 2:06 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: Ed Burns <Edward.Burns@xxxxxxxxxxxxx>
Subject: [External] : [jakarta.ee-spec.committee] Follow up actions from 2024-01-10 regarding Java SE level for EE 11
Hello Spec committee,
We consumed a lot of valuable time in the 2024-01-10 meeting on the matter of the Java SE level for EE 11. We discussed this at length in the platform project, in email, in ad hoc meetings, and at the platform project weekly meeting.
Here are the revisions to the EE 11 release plan devised by the platform project. I will copy from the email archive for your convenience.
-
Platform project keeps the June/July 2024 target for having an EE 11 Ratifying Compatible Implementation.
-
Platform project adjusts JDK compilation requirements:
-
Component spec TCKs and platform TCK must compile under 17.
-
A compatible component impl must pass their component TCK when run under 17 or 21.
-
To ratify a component specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
-
These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
-
A compatible platform impl must pass the platform TCK when run under 17 or 21.
-
To ratify a platform specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
-
These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
-
This is the same situation as was the case with Jakarta EE 10. For EE 10, it was JDK 11 and 17. For EE 11 it is JDK 17 and 21.
-
Wave 1, 2, 3, 4 specs release review by 2024-02-29
-
M2 release
-
Wave 5 specs release review by 2024-03-29
-
M3 release
-
Wave 6, 7 specs release review by 2024-04-27
-
M4 release
-
The key condition to make this plan possible: the GlassFish community is willing and able to deliver an implementation of EE 11 compiled under 17, but passing the platform TCK under 17 and also 21. The release coordinators
expect more community involvement on the Jakarta Data implementation for GlassFish, especially from Red Hat, to achieve this goal.
These changes have been applied to the release plan in PR 822. The important text is on lines 52 - 64 of the release plan.
Based on what I heard from Wayne in the 2024-01-10 call, no ballot is required for a plan change, because the release review that implements this change will include a vote.
Please let me know if further action is necessary.
Thanks,
Ed and Arjan
Jakarta EE 11 release co-coordinators.
| Reply anonymously to this email:
https://purl.oclc.org/NET/edburns/contact
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
|
