PMC, and project leads:
I intend to push the projects listed as "Review Documentation" at the bottom of this message through our first restructuring review to turn existing "Eclipse Project for ..." projects into specification projects.
Note that I'd like to have the Jakarta EE Platform project included in this list, but I need a little help with the scope statements (the platform project actually includes three specifications). I'll bring that forward as soon it's ready.
I'd like to send this list to the Specification Committee as soon as possible; if you have any feedback or concerns, or feel that a little extra wordsmithing is required let me know. I've also included an overview of the process that I'm following. Likewise, let me know if you've noticed something amiss with the process.
I'm tracking all of the change issues here. There's pointers to the scope and name issues in the individual cards.
My plan is to deliver this list to the Specification Committee with a request for them to vote to approve the conversion of the existing projects into specification projects. Per the process, we require a super-majority (2/3) affirmative vote to proceed. I'm presenting them as an all-or-nothing collection (we'll adjust this part of the process if there's a problem).
I will concurrently start a Restructuring Review per the EDP. I'll include the content below as the documentation for that review. Both the community review and the Specification Committee vote aspects of the Restructuring Review require a week; when that week is over, I'll declare success (assuming that we get the specification committee votes we required and the PMC gives me their approval)
With the successful conclusion of the review, I will convert the projects. As part of this, I will review the committer lists to ensure that we have all of the necessary agreements for all of the committers. I will retire any committers who do not have the necessary agreements in place (we'll reinstate them when we get the paperwork that we need). I will then update the project metadata based on the described changes.
Note that some of these projects will require some changes in the names of their repositories to respect trademark restrictions (e.g. "jaf-api" will become "activation-spec"). We will also have to change the ids of some projects. I've captured these changes in the project board that I cited previously.
With that all done, it will be left to the project teams to start with the work of creating specification documents. The PMC will provide guidance regarding the form of these documents. The short version is that for many of these specifications, we'll have to ask the project teams to create "placeholder" specification documents based on the project name, scope, and javadoc (more on this later).
We're working through an exercise to get the necessary rights to contribute the existing specification documents under the project licenses. At this point, I do not know which documents we'll clear first.
Regarding the existing specification documents... when I am able to do so, I will contribute the specification to the project via IPZilla (with project leads in CC). The project team can take the specification and drop it into their repository when the IP Team gives their approval (the IP Team is involved in the above-mentioned exercise, so approval will come immediately/quickly). The PMC will provide guidance to project teams regarding what needs to happen next.
Note that the PMC's recommendation is that the "API" repository be used as a home for both the API and for the specification document. We are moving forward based on this assumption. Since project teams will be the ones who will either create placeholder documents or take the existing document out of the IPZilla record, they will have an opportunity to request the the webmaster create a separate repository if that's what they prefer. Project teams may feel free to weigh in on the "convert" issues if they'd like to get ahead of it.
Note also that the specification documents that we have are all in Asciidoctor format.
I will track all of this activity in the "convert" issues. Monitor those issues to keep up with progress of the individual projects.
Jakarta RESTful Web Services defines a standard for development of web services following the Representational State Transfer (REST) architectural pattern.
Jakarta JSON Processing defines a Java(R) based framework for parsing, generating, transforming, and querying JSON documents.
Jakarta Activation defines a set of standard services to: determine the MIME type of an arbitrary piece of data; encapsulate access to it; discover the operations available on it; and instantiate the appropriate bean to perform the operation(s).
Jakarta Persistence defines a standard for management of persistence and object/relational mapping in Java(R) environments.
The Jakarta WebSocket defines how Jakarta based applications create and manage WebSocket Clients and Servers.