Xalan jar file is broken

[carlosame]

The latest Xalan jar file (released July 24, 2014) is xalan-2.7.2.jar, which claims to provide a service (via META-INF/services) with a non-existent class file. This breaks modularisation attempts with:

[ERROR] Error occurred during initialization of boot layer
[ERROR] java.lang.module.FindException: Module xalan not found, required by io.sf.carte.echosvg.dom

The issue was reported by @i-make-robots as XALANJ-2632 but was well known already:

• https://stackoverflow.com/questions/54682417/unable-to-derive-module-descriptor-provider-class-x-not-in-module
• https://issues.redhat.com/browse/WFLY-10279
• http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012147.html
• Moditect workaround

When Dan's issue was posted to the xalan-dev mailing list, he got a response from Joseph Kesselman @keshlam on that list. Here is an excerpt:

As far as I know, Xalan is not currently being actively maintained. I've been
considering putting some time into it.

Which are good news —at least for us, not sure about him ;-) given the current shape of that code— however Xalan-J is an ASF project, and even if a single developer is active he may not even be able to trigger a new release.

Meanwhile, I decided to look for ways to get rid of Xalan. This project uses Xalan to implement XPath support in the old Batik/EchoSVG DOM implementation, something that is used by the (deprecated) SVG 1.2 support. At some point the obsolete SVG 1.2 support is going to be removed (and hence Xalan or whatever XPath provider this project adopts), but only when the support for more modern CSS and SVG justifies that.

Another possibility was to refactor the code so Xalan is only used when available in the classpath/modulepath, but that's still problematic. And switching to a better XPath provider like Saxon HE would require too much coding for an already deprecated feature.

So today I finally forked Xalan and I'm experimenting with that fork (called EchoXSL). You can already browse the repository at css4j/echoxsl: it has a new Gradle build and the tests at least do compile (not without removing a few files that depended on classes that were removed long ago from Xalan).

For now, my intention is to use the new Xalan fork in EchoSVG 0.2 (planned for June). Comments are welcome.

[carlosame]

however Xalan-J is an ASF project, and even if a single developer is active he may not even be able to trigger a new release.

A recent example of this: EchoXSL depends on Xerces-j, and recently the only active Xerces-j developer attempted to release 2.12.3 with an important fix which would allow a modular release of EchoXSL (or Xalan, or any other Xerces-depending project).

Nobody else in the PMC voted, and the release did not happen:

https://lists.apache.org/thread/yf6z81nm0hwx5v3ggsvyhdhv5ffktjbz

I'll wait for Xerces 2.12.3 a bit, but otherwise I may release EchoXSL as it is now (without module-info files).

[carlosame]

EchoSVG now uses EchoXSL (first release was just produced) and everything seems fine.

Closing this, and EchoSVG 0.2 is ready for release from my point of view.