Reflect the runtime dependency on JAXB in the POM instead of mentioning it in the README

[jbisotti]

Not doing so violates the principle of least surprise.

[zubri]

This is a controversial subject since those APIs are available or not depending on the Java runtime you use.

Up to Java 8, those classes are included in the JVM. Adding it to the pom explicitly would be redundant and would force you to use a specific implementation of our choice, instead of using whatever is provided by your runtime configuration. Since the main branch and main current releases of the library are compiled and compatible with Java 8 as minimal requirement, not specifying jaxb as dependency sounds reasonable for the default pom configuration.

Since Java 9, the module became optional. It is not available by default, however you can switch the model on in your runtime configuration. So again, you have a choice here. You either add some specific implementation as dependency in your project, or you enable the module in the underlying JVM. But we still do not force specific dependencies in the pom for the same reason.

Since Java 11, those reference implementation have been removed. There are no longer available neither as optional module. So it is necessary to define them as external dependency. Thus, starting version 10.0.0-RC1 just release at Maven Central, the jaxb dependencies (now within a jakarta package) are explicit at the pom. BTW, this version includes migration to Java 11 and Jakarta EE 10.

[jbisotti]

With the latest 10.0.0 release, JAXB still does not show up as a transitive dependency -- only commons-lang3 & GSON do.

• https://mvnrepository.com/artifact/com.prowidesoftware/pw-swift-core/SRU2022-10.0.0
• https://repo1.maven.org/maven2/com/prowidesoftware/pw-swift-core/SRU2022-10.0.0/pw-swift-core-SRU2022-10.0.0.pom

[zubri]

We are adding it to the iso20022 project.

Not to Prowide Core since there we just use annotations (persistence, validation constraints).