Do not rely on javax. group ids

[wilkinsona]

A few years ago, we had an initiative across the portfolio to move away from the javax.* spec jars to their jakarta.* replacements. Since then, a few javax.* spec jars have snuck back in. Can you please replace your dependencies on javax.xml.bind:jaxb-api with dependencies on jakarta.xml.bind:jakarta.xml.bind-api instead. 2.3.3 is the latest Java EE 8 version and 3.0.1 is the latest Jakarta EE 9 version.

[rwinch]

@wilkinsona Thanks for the report. I think I'm missing the background on this. Can you help me understand what problems this is causing?

[wilkinsona]

Consistently using jakarta.xml.bind:jakarta.xml.bind-api across the portfolio reduces the risk of users ending up with two copies of the JAX-B API on the classpath. As things stand, we jump through some exclusion hoops in Spring Boot's starters to mitigate things but it's imperfect and it would be better tackled at source in each project.

Furthermore, javax.xml.bind:jaxb-api is no longer maintained. In the 2.x line, 2.3.1 is the latest version. If you switch to the new jakarta.xml.bind:jakarta.xml.bind-api coordinates, you'll see that 2.3.2 and 2.3.3 have been released.

[rwinch]

Thanks for the reply. Can you help me understand how a user would end up with this dependency on the path since it is not a published dependency? This will ensure I properly verify the changes resolve the problem.

[wilkinsona]

IIRC, spring-security-data's dependency on javax.xml.bind:jaxb-api is what caused me to open this issue. We have excludes in Boot (like this, for example) to avoid it polluting the classpath. Looking at a build scan , spring-security-cas may be affected as well but we haven't seen that in Boot as we don't depend upon it.

The goal is that a user can depend on spring-security-cas or spring-security-data and for that not to result in having javax.xml.bind:jaxb-api on the classpath. jakarta.xml.bind:jakarta.xml.bind-api should be present instead.