Deliver websocket-api Specification Version update for Jakarta EE 9 #322
Comments
Completed
Not Applicable
|
|
The jakarta websocket API 2.0.0-M1 is now present on maven central. Does that satisfy the Release Candidate (RC) of Jakarta API in Maven Central todo? |
|
Thanks, @joakime! Although the CI updates do belong to the Tyrus project, this Specification Project still has to monitor that progress. When the final PRs are delivered for the Spec and Apiddoc updates, one of the requirements for a new Specification Version is to reference a working CI that supports the updates. So, eventually, it will come into play... I equate Milestone drivers with RC drivers, so yes that would suffice. Do you have the Maven coordinates available? |
Here you go. <!-- for Server -->
<dependency>
<groupId>jakarta.websocket</groupId>
<artifactId>jakarta.websocket-api</artifactId>
<version>2.0.0-M1</version>
</dependency>
<!-- for Client -->
<dependency>
<groupId>jakarta.websocket</groupId>
<artifactId>jakarta.websocket-client-api</artifactId>
<version>2.0.0-M1</version>
</dependency>
|
|
Hi, I see websocket-all 2.0.0-M1 in Maven Central, but not the individual Server and Client APIs: Did these get published or are they still in a staging repo? |
|
Let me check the CI build. Note M1 is definitely a Milestone, not an RC. I was only looking to get a version out using the jakarta package for other projects that needed the dependency. I didn't check any other stuff at all. There could be all sorts wrong with it. |
|
Note Tomcat already has a working implementation of the new API so we don't necessarily have to wait on Tyrus. What we do need is the updated TCK. |
Per the TODO list it seems that we are on the hook for updating the TCK. Opinion: It would be easier (and faster) to develop a standalone TCK from scratch (like CDI / weld did) then updating the existing giant ball of spaghetti that is the official TCK. (Plus we can actually get proper coverage for the Client portions which the official TCK seems to have not done) |
|
The TCK project recently posted instructions for building and running the stand-alone TCKs. My plan was to build and run the WebSocket TCK and then see what needed to be changed for 2.0 (actually was going to start with EL as it is quicker to run but the same idea applies). I'd like to get a sense of how much work that is before contemplating a complete replacement of the TCK. My sense is that a complete replacement is far more work. |
|
Thanks for the information on mvnrepository, @joakime. Point well taken. FYI, some TCKs are standalone, others are part of the platform TCK. The idea of the checklist item is to track that the TCK needs to be updated accordingly. It may be members of the Spec project, it may be someone else. I thought the Web Socket TCK was already standalone, but maybe I'm mistaken. |
|
Also, on the Platform Call this morning, the difference between Milestone and RC drivers was explained. A Milestone driver is just one step towards a Release. It's very preliminary and considered not functionally complete. Release Candidates are used to show progress towards a final Release. To that end, we are interested in a Release Candidate URL for the APIs, not Milestone drivers. I'll clarify in my next note the wider team as well. |
|
The M1 release from WebSocket (and EL, Servlet and JSP when the PR is approved) are feature complete from a code perspective but I don't consider them good enough for an RC because I know I haven't checked anything else (e.g. version details in Manifest, copyright headers, changelogs, etc.). We should be able to do that fairly quickly but the intention, for those projects at least, was that the M1 would be 'good enough' for dependent projects to work with. The Servlet M1 and El M1 are good enough, for example, to enable JSP to progress. |
|
@markt-asf This sounds like great progress! I would suggest just creating RC releases for the APIs that you are referencing. That way everyone knows that the API is usable for testing. Milestone drivers have a different definition and, thus, users wouldn't know whether they should be used or not. Thanks! |
|
Can I ask this team to please create and assign the following labels to this Issue? Thank you! |
|
Now that we have come to the conclusion that Milestone APIs are sufficient for the respective column in our Project Plan, can I ask that we create a Notecard in the Project Board for your M1 jar files? Thank you! |
|
One last request for the Specifications PR to promote the Milestone deliverables for this Project. The PR is created against the Jakarta EE specifications github repo. A template is automatically used when creating PRs against this repo which should help with understanding the steps required for a successful merge. We're not looking for perfection for this Milestone. We just want the ability to promote the great work that all of the Projects are doing. If you submit a PR, please feel free to move this Epic to the Milestone 1 Ready column in the Project Board. Thanks! |
|
Looking for an update on the status of the Web Socket Final Specification PR. If we're going to make the Sept deliverable goal, then this Wave 1 Specification needs to be ready for final ballot by Monday, July 19. Which means that the Specification PRs should already be created and under a "mentorship" review. Can I ask what the plans are for this Specification? Thanks! |
|
Looks like the 2 specification PRs mentioned by @markt-asf were merged. |
|
WebSocket should be ready to go for the final release. I don't see any outstanding issues. I'll give it 24 hours or so and if no objects start the release process for 2.0.0. |
|
Had a look around at the open/closed issues, i'm good with the release of 2.0.0 as it stands right now. |
|
Any news to report regarding preparation of WebSocket materials for Jakarta EE ballot? From the Spec PR perspective, there are several items that need to be completed before we can begin the approval ballot for WebSocket. These should be itemized in the checklists associated with the Specification PR (here).
Is there anything I can do, to help move this to ballot stage? Is there anything else blocking progress with this? |
|
I am back after a few weeks away and am still working my way through the backlog of work that built up. I'm aiming to get to WebSocket this week. |
|
I just reviewed and fixed a small number of things in the TCK documentation (see Jakarta EE TCK PR 492). I believe the TCK docs are now sufficient for release. Please verify and approve. Once you are satisfied the TCK is running as expected and you have confirmed the zip file contents (look for a TCK built after Sep. 2, 2020), please add a comment to this issue so that the TCK will be promoted (and builds will stop). |
|
@edbratt I've looked but I can't find a build dated later than Sept 2, 2020. The latest build I could find did not include the fixes you referenced in the previous comment. |
|
@markt-asf I confirm that there are no recent Websocket TCK builds. I asked @alwin-joseph to re-stage it jakartaee/platform-tck#395 (comment) |
|
Jakarta WebSocket 2.0.0 is still staged at https://jakarta.oss.sonatype.org/content/repositories/jakartawebsocket-1009/ |
|
I think it might need to be re-staged to pick up the JPMS module name changes, |
|
Want me to ...
? |
|
Perhaps even drop the |
|
Here's the list of differences between |
|
@markt-asf opened PR #360 to reset the |
|
Personally, I'd drop the 2.0.0 branch entirely but I'll that choice up to you. |
|
My tasks currently ...
|
|
New staged |
|
@markt-asf can I get a review of that staged websocket api? |
|
LGTM. |
|
I think this is done / completed. right? |
|
Closing as complete |
Is your feature request related to a problem? Please describe.
Jakarta EE 9 is the next major release, with the main focus of moving from the
javaxnamespace to thejakartanamespace.Describe the solution you'd like
This issue will be used to track the progress of this work effort via the Jakarta EE 9 Project board.
Additional context
Jakarta EE Specification Process
Eclipse Project Handbook
Eclipse Release Record for Jakarta EE 9
ToDo
Most Component Release Records will just reference the Jakarta EE 9 Platform Release Plan. But, if your Component deviates at all from the Platform Release Plan, then a description of the changes will be required in the Release Record.
https://projects.eclipse.org/projects/ee4j.websocket/releases/2.0
Initiate a ballot for your Jakarta Release Record/Plan.- n/aAgain, if your component is only doing the required minimum as defined by the Jakarta EE 9 Platform Release Plan, then no separate ballot is required. You are already approved. But, if your component deviates from the Platform Release Plan, then you will need to initiate your own ballot as defined by the Jakarta EE Specification Process.
Many of the Jakarta EE components now have the source for their Specification documents. It is strongly recommended that these Specification documents are properly updated to represent Jakarta EE instead of Java EE. Some helpful instructions are documented here.
If your component has Specification source, then all javax package references need to be updated to use jakarta package references.
Your component APIs need to move from using the javax namespace to using the jakarta namespace.
A Release Candidate of your component API should be pushed to Maven Central as soon as humanly possible. This will allow other dependent components to utilize your APIs as they are updating their APIs. Multiple revisions of these Release Candidate APIs are allowed (and probably expected) during the development cycle.
Your component TCK needs to be updated to use the jakarta namespace.
Your compatible implementation that will be used to demonstrate completeness of the Specification needs to be updated to use the jakarta namespace.
When ready, your final version of the API needs to be staged to get ready for the PR review and approvals.
Like we did for Jakarta EE 8, draft PRs need to be created and reviewed in preparation for the final ballots.
Each Jakarta EE component will need to initiate a separate Release Review ballot after proper reviewing has completed. To be clear, there will not be a blanket Release Review for all of Jakarta EE 9 like we did for the Plan Review. Each component needs a separate Release Review.
The text was updated successfully, but these errors were encountered: