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 fogtime. 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