I've been sitting on this for a while. I'm sure that many of us have recognised that we don't actually have obvious projects for all specification documents. We should come to some consensus regarding what we're going to do with the corner cases.
I've captured the content below in a Google Doc in the specification committee's team drive. Feel free to comment there or make suggested edits. I'll update the document based on any discussion that occurs in this thread.
The basic plan is to take existing “Eclipse Project for …” projects and turn them into specification projects. When we do this, we will update the project name and scope. The project name will be the same as the specification name.
There are a handful of exceptions that we need to think about.
We currently do not have existing projects for some specifications. My recommendation is that we create specification projects for each of these specifications initially as a home for just the specification document with an aspiration project scope that includes the API and TCK.
Bean Validation (Jakarta Bean Validation)
CDI (Jakarta Contexts)
Dependency Injection (Jakarta Dependency Injection)
JavaServer Faces (Jakarta Server Faces)
atinject? (Jakarta Inject?)
From the perspective of the EDP and EFSP, it is a valid state to have, for example, a “Jakarta Server Faces” specification project as the home for the specification document with an aspiration project scope that includes the API and TCK, but leave the APIs in Eclipse Mojarra for the foreseeable future. Whether or not this is a desirable state may be worth discussing.
We can convert Eclipse Mojarra into a specification project, but for consistency I recommend that we create a new Jakarta Server Faces specification project and leave Mojarra alone.
The following specifications (with existing “Eclipse Project for …” projects) feel like obvious candidates to just turn into specification projects, but--like Eclipse Mojarra--they include both the APIs and a reference implementation (I believe that they only feel like obvious candidates to just convert into specification projects because of their names). My recommendation is to just run with it and turn the corresponding “Eclipse Project for …” projects into specification projects.
Concurrency Utils (Jakarta Concurrency)
_expression_ Language (Jakarta _expression_ Language)
JAF (Jakarta Activation)
JavaMail (Jakarta Mail)
Java Message Service (Jakarta Messaging)
JSTL (Jakarta Standard Tag Library)
What do we do with the specification documents related to specification contents in the Eclipse Project for Stable Jakarta EE APIs. My recommendation is to turn this project into a specification project named “Jakarta EE Stable APIs” and create a single Git repository to manage all of the specification documents (we can split the Git repository if we decide that it is necessary to do so at some point in the future.
Enterprise Web Services
Enterprise Deployment
JAX-RPC
JAXR
Enterprise Management
