Fixes NPE within the API. Very questionably how any implementation could have passed this, unless they used a different API artifact from the official released one (which we allow)
OR… expression language is a pure client side test, and it always picks the expression language AP jarI that you want it to test LAST(!).
There’s 1 API jar coming in as a dependency from the TCK itself (!), which is used for the tests before the one you want to be tested
If your runner uses a parent pom, possibly multiple jars will be on the classpath
Arjan has staged this service release and is seeking feedback. ACTION: If no feedback, Arjan will release it. See JEA-407.
ACTION: Update dependency version in jakartaee api project.
Connectors JEA-417 ACTION: Ed needs to understand the impact of this on EE 11.
EL
ANSWER: Yes, let’s cut an RC1 when these are in.
Milestone release process
Ed Bratt wrote: “Are you using the Github Release / Tags feature when you make Platform releases? If not, I wonder if we might want to consider that?”
No, but we should have been doing that. I have filed JEA-408.
Conversation on https://github.com/jakartaee/platform/pull/746 seems to be going well, not sure if there are any more questions pending regarding A prototype of adding persistence requirements for CDI in EE environments
We need implementations to try it still.
We also need a list of what will not work with Persistence CDI in EE.
I think we are waiting on Faces team to agree that a user workaround is approved of ignoring the test failure on Java 21.
The Faces 4.0.x branch needs someone to fix a build failure, not sure when that might happen. Otherwise, we would try to fix the failing test.
Any concerns?
Jakarta EE 12
Some discussion about removal of Application Client in EE 12. See JEA-414.
ACTION: Nathan raised a good question about dependencies and javadoc.
What is the guidance for spec JavaDoc that wants to link to a different spec JavaDoc that wouldn’t otherwise be a dependency? For example, if JavaDoc includes {@link Resource}, this adds value to the user who can follow the link, but it comes at the cost of the spec declaring a dependency on Jakarta Annotations. If the JavaDoc instead refers to it as {@code jakarta.annotation.Resource} then there is no dependency, but there user isn’t able to follow a link to the JavaDoc for Resource. This scenario comes up often enough. Is there any recommendation or requirement on which direction we should be taking?
Lukas Jungmann had some other observations about this. If the spec makes a behavioral dependency on another spec, should this be encoded in the POM?
