Decide whether to stop excluding xalan and serializer

[ctrueden]

The ome:formats-api and ome:formats-bsd and ome:bio-formats-tools components have runtime dependencies on xalan:xalan and xalan:serializer. Right now pom-scijava excludes these dependencies—and also from org.apache.xmlgraphics:batik-bridge and org.apache.xmlgraphics:batik-dom and ch.qos.logback:logback-classic—for reasons that have been lost in the mists of ~~my brain fog~~time. Downstream, the Fiji project needs to ship these components as part of its distribution so that certain Bio-Formats XML-related functionality works properly; otherwise, there are errors, which have also not been diligently recorded anywhere as far as I can remember.

So: once and for all, we should:

1. Write down here what goes wrong at runtime if xalan and serializer are not present, in which scenarios;
2. Write down here what goes wrong at build time, if anything, if xalan and serializer are unexcluded; and
3. Make a final decision on how to proceed so that both build time and runtime are happy, such that sc.fiji:fiji exposes its needed dependencies on xalan and serializer at an appropriate scope, optionally or not as appropriate.

[ctrueden]

One thing I do remember about this: on multiple occasions I attempted to remove xalan and serializer from Fiji, wondering why they were actually necessary, since they contain classes also bundled with the core Java library. But every time I tried to do it, it would break some XML-related logic deep in Bio-Formats when reading certain file formats. I think this is because the version of the XML code bundled with the Java standard library was/is buggy compared to the xalan version that Bio-Formats uses. That said, it is worth testing again with a newer JDK version, at least 11 if not 21, to see how Bio-Formats behaves now. Unfortunately, to do that, we would first need to replicate the original problem with the Java 8 version of the JDK. So we need to find a sample file whose import becomes broken when xalan and/or serializer are removed from the runtime.

[elect86]

I might give a look on how to replace that with modern jdk xml support

But I'd need to have some test case scenario to test it on