As part of its move to Eclipse and rebranding from Java EE to Jakarta EE some of the API dependencies have been published with new versions under a jakarta.* group ID. Furthermore, some of the reference implementations have switched from Java EE API dependencies to Jakarta EE API dependencies in their latest maintenance releases (#15689 and #15915). We've avoided those upgrades in 2.1.x as we do not feel that the switch is appropriate for a maintenance release. We need to bite the bullet in 2.2 to avoid being stuck on older versions.
Once #15689 and #15915 have been fixed, we'll be left with a mixture of Java EE dependencies and Jakarta EE dependencies and in some cases we'll be left with both variants on the classpath at the same time. This issue is intended to tidy up that mess as much as possible. We'll move to Jakarta EE dependencies wherever possible in our own build and in the dependencies provided by our starters. We can use the enforcer plugin to prohibit javax.* dependencies with a few exceptions where a Jakarta EE API dependency has yet to be published.
Comment From: jhoeller
@wilkinsona, are there any known issues with the dependencies that we declare in the Spring Framework POMs for your Jakarta EE purposes in Boot 2.2? Do you have to apply any manual excludes there?
For the time being, it seems sensible to stick with the original Java EE artifacts in the Spring Framework build since we need to compile against EE 7 level in a few places... and those older API versions are only available under the original Java EE coordinates. We only really need the EE 8 API level for some optional pieces... but nothing beyond it yet that would only materialize under Jakarta EE, at least not for our core compilation purposes. Also, our current optional dependencies and test dependencies are all referring to the original Java EE artifacts still, leaving a clean classpath for us for our build arrangement.
That said, if there are issues with our use of those original EE artifacts, e.g. them shining through for some of our optional dependencies and requiring manual excludes, I'm happy to consider a revision within the Spring Framework 5.2 timeframe.
Comment From: wilkinsona
Thanks for asking, @jhoeller. I didn't have to exclude anything from our Framework dependencies to make the switch.
Comment From: driverpt
@wilkinsona , can you ensure that this https://github.com/eclipse-ee4j/servlet-api/pull/271 is included in the new release when it's merged? Google Chrome is going to start enforcing SameSite cookie policy.
Comment From: wilkinsona
That change isn't going to be in a release of the Servlet API until 5.1. We'll pick it up when it's available, but that's likely to be several months away. We're investigating doing something for embedded containers without official spec support in https://github.com/spring-projects/spring-boot/issues/15047.