You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spring WS currently depends on com.sun.xml.bind:jaxb-core; other projects in the ecosystem moved to the org.glassfish.jaxb variants instead. This causes duplicate JARs on the classpath and issues during repackaging.
Can Spring WS consider dendending on the latter?
It seems that both variants contain the same classes, with different packages. Is the application code supposed to directly refer to those classes? Maybe this change can be applied safely without any impact for developers?
The text was updated successfully, but these errors were encountered:
@bclozelcom.sun.xml.bind:jaxb-impl is runtime-scoped, so there should be no expectation for any applications to directly depend upon this artifact. Instead, applications, at best, are to lean on the APIs in jakarta.xml.bind, javax.xml, etc. if they aren't simply using our APIs (which this shouldn't break).
See spring-projects/spring-boot#33659 for background.
Spring WS currently depends on
com.sun.xml.bind:jaxb-core
; other projects in the ecosystem moved to theorg.glassfish.jaxb
variants instead. This causes duplicate JARs on the classpath and issues during repackaging.Can Spring WS consider dendending on the latter?
It seems that both variants contain the same classes, with different packages. Is the application code supposed to directly refer to those classes? Maybe this change can be applied safely without any impact for developers?
The text was updated successfully, but these errors were encountered: