Q1: Is this project API version working under a current, approved Specification Plan?

Q1.1: Please describe the focus areas of work underway for this API project team (what is this specification project team doing now):

Q1.2: What changes does this project team expect the next release of this API project will contain (regardless of when these changes might be completed)?

Q2: Does your project team intend to make an API release for Jakarta EE 11?

Q2.1: Do you believe these changes are achievable under the milestones described in the Jakarta EE 11 proposal with the resources you have available today?

Q2.2: Are you able to suggest an estimate of time (to the nearest month, or quarter) that could work for this API project?

Q2.3: Please provide any details that might help the Platform Team understand why not

Q3: What version of Java SE do you plan to use as your next API base (recall, generally only upgrade when needed for specific API features)?

Q4: Is your stand-alone specification TCK produced via the Jakarta EE TCK Project?

Q4.1: Do you plan to refactor your TCK out of the Jakarta EE TCK Project?

Q4.2: Please provide a target date for concluding this refactoring and also list any issues/concerns/resources that you have regarding this effort

Q4.3: Please, briefly explain why this is not feasible at this time

Q5: Are you aware of any Jakarta EE specification project (or projects) that is (are) dependent on work completed or planned by this specification?

Q6: Are you aware of any dependencies this project has, on work considered or planned by other Jakarta EE specification projects?

Q7: Is there anything the platform committer team can do to help facilitate your project API development efforts?

Q8: Are there vendors signed up to support your specification in an EE 11 implementation?

Q8.1: Which vendor(s) is/are signed up to support your specification?

Santiago Pericas Geertsen

Minor adjustments to the API.

We expect to adjust the API to support the updated specifications we depend on to be able to run in a Jakarta EE 11 envirionment.

Jakarta RESTful Web Services

Various issues raised in the spec project

@Priority on Sterotypes do not enable an Alternative as per the Spec

Accessing custom context objects in CDI Lite

Remove the JBoss reference from copyright and license headers

List of potential changes/features for next CDI version

Move jakarta.el-api related method to new BeanManager subclass?

Review unused imports in classes in CDI 4

Getting interceptor bindings in standard way

@Priority on producers

Programmatic access to Assignability rules

Executable methods

Add methods to BeanConfigurator for applying decorators

How can getReference() legally be invoked during AfterDeploymentValidation event if contexts have not been created yet?

This is a maybe at this point

Working through open issues and addressing them. Mostly minor enhancements and clarifications of existing behaviour.

Remove SecurityManager references (done), address as many open issues as possible (in progress), introduce low level HTTP API (may or may not happen - still be discussed)

Split out the Servlet TCK into a separate project.

Eclipse Jetty, Apache Tomcat, Undertow/Wildfly

Monitor Servlet and EL specs for further changes that require updates to this project.

Remove deprecated code (complete). Fix open issues (complete). Changes required as a result of updates to the Servlet and/or EL specs (complete as of time of writing).

Benefits do not justify effort required.

None at this time. Monitoring Servlet and Pages in case that changes.

Address open bugs (not started), Address selected enhancement requests (not selected, not started)

Benefit id refactoring doe snot justify effort required.

No new features are planned

No new features are planned

was merged into Jakarta XML Web Services specification in EE 10

We created the plan, however, it was not reviewed yet:

https://projects.eclipse.org/projects/ee4j.nosql/releases/1.0
https://github.com/jakartaee/data/pull/123

We want to release a MVP as first release, with three annotations and three APIs Templates for Document, Key-value and Column

We need to create the TCK, but, as Jakarta Data we have an issue with the TCK with Arquillian.

Is there something more modern and simpler to use instead of Arquillian?

Is there any plan to work on it?

We created the plan: https://projects.eclipse.org/projects/ee4j.data/releases/1.0
We'll submit the spec for review soon.
The initial idea is for have the Repository Feature.

Release the Repository feature.

We need to create the TCK, but, as Jakarta NoSQL we have an issue with the TCK with Arquillian.

Is there something more modern and simpler to use instead of Arquillian?

Is there any plan to work on it?

IBM (Openliberty) https://github.com/OpenLiberty/open-liberty

Split API from Mojarra implementation to separate spec project
Consider to remove class scanning and rely on CDI only
Amount of small enhancements, like add missing generics hat were missed in Faces 4.0, Enhance UIInput events with HTML5 like oninput, id attribute is missing in vdl of h:head and h:body, etc

A separate API, further CDI alignment, and quality of life changes

Not really. Jakarta MVC had a sort of dependency, but that might not longer be the case.

Jakarta Faces is strongly dependent on Servlet, CDI and Expression Language, so any changes there may effect Faces. The considered Core HTTP API (split from Servlet and REST, should it happen) may effect Faces.

Jakarta Authentication and Jakarta Authorization have just been grouped into this specification, so they are obviously all interdependent on each other.

Yes, Jakarta Security greatly depends on the ongoing discussion of the two HTTP stacks in Jakarta EE, and the alignment with Core Profile (which uses REST) and the Micro Profile (which uses Core Profile, and therefor REST as well).

There are also various enhancements the Jakarta Security team would like to see in Jakarta CDI; Jakarta Security uses CDI very intensively and may therefor be a frontrunner to discover what is needed in CDI.

We are generally low on resources, and input and contributions for our Jakarta EE 10 version (Security 3.0) could be better.

The platform team may also play a role in convincing the Jakarta Servlet and Jakarta CDI teams that there are platform concerns (in this case for Jakarta Security) that go beyond their own direct goals.

We are considering changes to obtain the actual interceptor bindings from an Interceptor, in coordination with the Jakarta CDI team. Among many options considered it's possible that the change will be done on the CDI side, but we're not ruling out an Interceptor API update either.

The ability to obtain interceptor bindings from an interceptor, if any, without the need to inspect the target class or method using reflection.

Jakarta CDI will be directly dependent. Jakarta EJB potentially in a minor or trivia way.

The work will be coordinated between CDI and Interceptors, so there's a potential mutual dependency.

Nope. Do note that regarding the TCK question, Interceptors does not have its own TCK at all. It's tested via CDI and/or EJB.

Continual improvements to the specification

ongoing planning - preliminarily separated tcks, stateless sessionmanager, SQL functions in JPQL

No, unless we see progress on jakarta config in a reasonable timeframe

Nathan Rauh (needs approval from Steve Millidge who is the Concurrency Lead)

Draft plan: https://projects.eclipse.org/projects/ee4j.cu/releases/3.1/plan

Virtual Threads, CDI-centric, Replacements for EJB function, TCK enhancements

Virtual Threads, CDI-centric, Replacements for EJB function, TCK enhancements

No, the Sept 19 release date of Java 21 does not leave enough time to properly cover virtual threads and related technologies and to expect any compatible implementation to be available.

Ensure all of the component specification groups are looking at the impact virtual threads might have on their async programming models

IBM (Open Liberty) and probably others