Ok, thanks for the clarification. I’ll go ahead and close this out then.

Excluding the new version of JAXB looks fine.

The version of Hibernate we’re using references the OLD version of JAXB, which is what you’re seeing with those 2.3.3/2.3.6 version numbers. That’s expected.

As long as it’s “only” Hibernate pulling it in we will address that in 5.0 so that’s probably good enough for now. It was the timing of their transition to Jakarta that worried me here in case we got into a situation where they depended on it and we’re obviously running on a non-Jakarta container.

I have updated the parent POM to exclude the nominal JAXB dependency and it seems to be working as expected vis-a-vis Santuario’s dependencies. The OpenSAML and IdP tests all run fine with the exclusion.

Note however that as of at least 2.1.7 and including 2.3.0, the dependency’s coordinates are actually now the Jakarta version, which is what I have actually excluded here:

More importantly, though, this isn’t actually resulting in this being effectively excluded from our projects. hibernate-core still has a dependency on this, transitively via its dependency on org.glassfish.jaxb:jaxb-runtime:

Is this known/expected, etc? I do see that in the parent POM for hibernate-core, there is an exclusion for javax.xml.bind:jaxb-api, but this obviously isn't covering the org.glassfish.jaxb and jakarta.xml.bind stuff.

It might be interesting to add a check to the pom checker that no excluded artifacts get shipped, But equally if we don’t trust maven to do something as explicit as this what do we trust it to do? Remember that the initial issue was because maven was chosing the ‘wrong’ version of an artifact (because of the mess that is inherited dependencies)