Clash between Java package in standard library versus Maven artefact (Apache Batik)

Question

Trying to use Apache Batik for SVG export in my modular, Maven-based Java project, I'm running into a problem for which I wonder if there is any decent solution at all.

Adding the required Batik dependency to my POM:

            <groupId>org.apache.xmlgraphics</groupId>
            <artifactId>batik-dom</artifactId>
            <version>1.16</version>

gives rise to the following error:

The package org.w3c.dom is accessible from more than one module: java.xml, [...], xml.apis

Yes, indeed, both java.xml (which is in the standard Java 17 library) and xml-apis (which is part of batik-dom) contain the offending package org.w3c.dom. I cannot do anything about the first, but I can tell Maven to exclude the second:

            <groupId>org.apache.xmlgraphics</groupId>
            <artifactId>batik-dom</artifactId>
            <version>1.16</version>
            <exclusions>
                <exclusion>
                    <groupId>xml-apis</groupId>
                    <artifactId>xml-apis</artifactId>
                </exclusion>
            </exclusions>

Now the project compiles, but throws a run-time error: java.lang.ClassNotFoundException: org.w3c.dom.xpath.XPathEvaluator

It turns out the missing class org.w3c.dom.xpath.XPathEvaluator is in the xml-apis sub-module of batik-dom but isn't in the standard Java library module java.xml. In fact, the whole subpackage org.w3c.dom.xpath is absent from java.xml.

I'll admit I'm stumped. The only solution I can see is to wrap up org.w3c.dom.xpath myself in a separate module and include that as a local dependency. I'd be very grateful for an alternative (better) solution. After all, doesn't this problem occur for whoever wants to use batik-dom in a Maven-based project?

Answer 1

A continued search coughed up a solution to my particular problem, though I think this type of issue remains problematic in general. I feel that the exclusion mechanism in Maven just isn't fine-grained enough, depending as it does on the choices of the artefact developers on what to include in which (sub)artefact.

In any case, it turns out the disappearance of org.w3c.dom.xpath from the standard Java library was noted as a JDK bug some time ago, which was then resolved by moving the package to a separate JDK module, jdk.xml.dom. By adding

    requires transitive jdk.xml.dom;

to my module-info, the missing package is now part of my build.