Wave discussion: Refine wave list from 681 and apply to Plan document

[edburns]

Here is the Wave list from @JanWesterkamp-iJUG from #681 .

The (current) result for API dependencies (only):

Wave 1:

• Jakarta Activation
• Jakarta Annotation*
• Jakarta Authentication
• Jakarta EJB
• Jakarta EL
• Jakarta Lang Model
• Jakarta Inject
• Jakarta JSON
• Jakarta Persistence
• Jakarta Security
• Jakarta Servlet
• Jakarta Validation
• Jakarta REST
• Jakarta Websocket Client

Wave 2:

• Jakarta Authorization
• Jakarta Interceptor*
• Jakarta JMS
• Jakarta JSON Bind
• Jakarta Mail
• Jakarta Servlet JSP
• Jakarta Websocket
• Jakarta XMP Bind
• Jakarta XML SOAP

Wave 3:

• Jakarta CDI*
• Jakarta Servlet JSP JSTL
• Jakarta XML WS

Wave 4:

• Jakarta Batch
• Jakarta Concurrent
• Jakarta Transaction*
• Jakarta Platform Web Profile

Wave 5:

• Jakarta Faces*
• Jakarta Ressource

Wave 6:

• Jakarta Platform Web Profile*

Wave 7:

• Jakarta Platform*

*critical path

Let us use this issue to iterate the discussion and ultimately apply the work to https://github.com/jakartaee/jakartaee-platform/blob/gh-pages/jakartaee11/JakartaEE11ReleasePlan.md

AB#6

[edburns]

@edburns : create “diff” style rendering of existing and proposed to start off discussion on platform-dev.

[JanWesterkamp-iJUG]

@edburns : The mailing list should be jakartaee-platform-dev, right?
platform-dev exists too, but has a different scope.

[edburns]

@JanWesterkamp-iJUG wrote on Signal:

Hi Ed, I will miss the Jakarta Platform meeting today and potentially next week because of the JSail unconference.
If you need more jQA analysis for the wave reordering, please tell me.
Meanwhile I updated to the jQA 2.0.1 and Dirk already fixed some of the issues - so it can be used for Jakarta Platform already (and the new rendering looks very nice!).
I also rerun the analysis for the Jakarta Validation TCK to realign it (the API has no dependency, so currently it is in wave 1). I am a little bit shocked about TCK version 3.0.1 (that belongs to 3.0.0+), as it depends on version 3.0.0 of the API an a lot of non-final versions of other dependencies including CDI, which puts it into wave 4 instead of 1.

[edburns]

Here is the promised diff for discussion.

--- em-2529-waves-01-ivar.txt	2023-05-23 10:43:59
+++ em-2529-waves-02-jan.txt	2023-05-23 10:43:28
@@ -1,50 +1,54 @@
 Wave 1:
 
 Jakarta Activation
+Jakarta Annotation
+Jakarta Authentication
 Jakarta Bean Validation
 Jakarta Dependency Injection
+Jakarta Enterprise Beans
 Jakarta Expression Language
-Jakarta Interceptors
 Jakarta JSON Processing
-Jakarta SOAP with Attachments
+Jakarta Lang Model
+Jakarta Persistence
+Jakarta RESTful Web Services
+Jakarta Security
 Jakarta Servlet
-Jakarta WebSocket
+Jakarta Websocket Client
 
 Wave 2:
 
-Jakarta Authentication
 Jakarta Authorization
-Jakarta Debugging Support for Other Languages
+Jakarta Enterprise Web Services (XML SOAP?)
+Jakarta Interceptors
+Jakarta JMS
 Jakarta JSON Binding
 Jakarta Mail
 Jakarta Server Pages
-Jakarta XML Binding
+Jakarta Websocket
+Jakarta XML Binding (XMP Bind?)
 
 Wave 3:
 
 Jakarta Contexts and Dependency Injection
+Jakarta Standard Tag Library
 Jakarta XML Web Services
 
 Wave 4:
 
 Jakarta Batch
-Jakarta RESTful Web Services
+Jakarta Concurrent
+Jakarta EE Platform Web Profile
 Jakarta Transactions
 
 Wave 5:
 
-Jakarta Connectors
-Jakarta Enterprise Beans
-Jakarta Enterprise Web Services
-Jakarta Standard Tag Library
+Jakarta Resource
+Jakarta Server Faces
 
 Wave 6:
 
-Jakarta Security
-Jakarta Server Faces
+Jakarta EE Platform Web Profile
 
 Wave 7:
 
-Jakarta EE Platform Core Profile
 Jakarta EE Platform Full Platform
-Jakarta EE Platform Web Profile

[edburns]

em-2529-waves-01-ivar.txt
em-2529-waves-02-jan.txt
em-2529-waves-03-merged.txt

[edburns]

Hello @JanWesterkamp-iJUG , can you please attach the diagram?

[JanWesterkamp-iJUG]

Hello @edburns, which diagram you mean?

If you meant the mentioned separate issue for the jQA reports, this is created: #687
I added reports for a lot of components specs and the separated TCKs I can found.

There are some issues, some could be solved by changing the wave of the API to one that fits the TCK too (i.e. Jakarta Validation). But some create a circular dependency, when the TCK is created with the API (i.e. Jakarta JSON Bind, Jakarta CDI)!

In general, a lot of the separated TCKs are created with a deviating environment compared to the corresponding API - this must be fixed!
As known already, APIs of component specs use a deviating environment than their umbrella spec and we have API dependencies to implementations and (outdated) test frameworks too.

May be, we should use the Jakarta Architecture Call in two weeks of discuss how to solve this?

I will be on JSail this week, so I can not promisse to make it to the call tomorrow, but I will try to...

[JanWesterkamp-iJUG]

@edburns, @arjantijms Here is an update for the waves, derived from the CN4J Report results.

Note:
PlantUML (operations research) does the job here now :-)
However, it shows the last possible wave for a component spec to release - instead of the possible first one before.
Already separated TCKs of component specs and their dependencies taken into account - spec document dependencies not (yet, see here).
To keep this operational, circular dependencies need to be prevented!

Wave 1:

• Jakarta Annotation

Wave 2:

• Jakarta EL
• Jakarta Interceptor
• Jakarta Inject
• Jakarta Lang Model (may be released with Jakarta CDI [Core] in wave 3)

Wave 3:

• Jakarta Activation
• Jakarta CDI [Core]
• Jakarta JSON
• Jakarta Transaction

Wave 4:

• Jakarta EJB
• Jakarta JSON Bind
• Jakarta Mail
• Jakarta Connectors (Jakarta Ressource in Maven)
• Jakarta Servlet
• Jakarta Websocket Client (may be released with Jakarta Websocket in wave 5)
• Jakarta XML Bind
• Jakarta XML SOAP

Wave 5:

• Jakarta Authorization
• Jakarta Batch
• Jakarta Persistence
• Jakarta REST
• Jakarta Servlet JSP
• Jakarta Validation
• Jakarta Websocket
• Jakarta XML WS

Wave 6:

• Jakarta Concurrent
• Jakarta Messaging (Jakarta JMS in Maven)
• Jakarta Faces
• Jakarta Servlet JSP JSTL
• Jakarta Platform Core Profile (may be released with Jakarta Platform in last wave)

Wave 7:

• Jakarta Authentication
• Jakarta CDI Web (new)
• Jakarta Security

Wave 8:

• Jakarta Platform Web Profile (may be released with Jakarta Platform in last wave)
• Jakarta CDI Platform (new)

Wave 9:

• Jakarta Platform

[JanWesterkamp-iJUG]

Alternatively, when the CDI TCK dependencies causing circular dependencies moved with their tests to the Jakarta Platform Web Profile and Jakarta Platform specs and all Jakarta Platform specs released together, the following changes apply:

...

Wave 6:

• Jakarta Authentication
• Jakarta Concurrent
• Jakarta Messaging (Jakarta JMS in Maven)
• Jakarta Faces
• Jakarta Security
• Jakarta Servlet JSP JSTL

Wave 7:

• Jakarta Platform Core Profile
• Jakarta Platform Web Profile
• Jakarta Platform

[JanWesterkamp-iJUG]

Reviews welcome!

[hantsy]

What is Jakarta Resources and Jakarta CDI Web?

[edburns]

Jan and I are discussing this in AB#98.

[arjantijms]

@JanWesterkamp-iJUG CDI API has references to things like Servlet (injecting HttpServletRequest) and transactions (injecting UserTransaction).

[JanWesterkamp-iJUG]

@JanWesterkamp-iJUG CDI API has references to things like Servlet (injecting HttpServletRequest) and transactions (injecting UserTransaction).

@arjantijms do you mean the API has references to Servlet and Transaction or the spec document?
The last would make sense, as older versions (3.x.y) had that dependencies before the clarification was done and the circular dependency with Transaction was removed (since 4.0.1).
So I can model them again, but reintroducing the circular dependency would make things worse. In the case of Servlet it could be tracked (if not solved/removed) - there is also a TCK dependency from REST here.
For the Transaction issue, we should remove it from the spec doc and also definitly make a (Major?) Release of Transaction to get rid of the circular dependency (to an old CDI version that again references CDI) - this was technical debt left from Jakarta EE 10 unfortunately.

[JanWesterkamp-iJUG]

What is Jakarta Resources and Jakarta CDI Web?

@hantsy, Jakarta Resources is the artifact name in Maven for Jakarta Connectors, like Jakarta JMS is still in use for Jakarta Messaging - I updated the waves according to that for clarification.

Jakarta CDI Web is a splitted CDI for the Web Profile to extend the CDI Core (Profile) or currently called CDI Lite from the CDI "Full". For Details check @edburns comment and the follow up with @starksm64, who created an issue within CDI to track this:

jakartaee/cdi#687

I created the speparated CDI Web and CDI Platform specs here especially to generate the wave contents and workaround the circular dependencies - the final solution depends on the ressources that could be invested on refactoring within the CDI spec team of course.

Or in more detail on resources on refactoring (splitting up the Platform TCK) the TCKs of specs above CDI in the dependency tree, that require integration testing with CDI and where the current problematic CDI test should be moved to finally.

[JanWesterkamp-iJUG]

@edburns, as noted, there is an issue in jQA for handling package type "bundle", which leads to not showing dependencies when treated as type "jar".

Jakarta Security is updated now manually, which has some influence on the waves:

...
Wave 6:

• Jakarta Authentication
• Jakarta Concurrent
• Jakarta Messaging (Jakarta JMS in Maven)
• Jakarta Faces
• Jakarta Servlet JSP JSTL
• Jakarta Platform Core Profile (may be released with Jakarta Platform in last wave)

Wave 7:

• Jakarta CDI Web (new)
• Jakarta Security

Wave 8:

• Jakarta Platform Web Profile (may be released with Jakarta Platform in last wave)
• Jakarta CDI Platform (new)

Wave 9:

• Jakarta Platform

So, Jakarta Authentication moves from Wave 7 to Wave 6.
If a separate, new CDI Web spec is not created, then the CDI integration testing might be done in wave 7 may waves. The Platform/Profile specs could then be released together in wave 8.

[JanWesterkamp-iJUG]

I also updated the CN4J Report here.