Circumvent old java meta-inf / services when using Java modules

I am trying to make a Java FX application showing an SVG-image using the Batik-library, but I'm having issues getting all the components properly imported.

After about 5 hours of searching and testing I have finally altered one of the dependencies' jars to remove old Java service (or whatever you call it) that predates the current module system. So the current work-around is to manually remove the "META-INF/services/org.apache.batik.script.InterpreterFactory"-file in "batik-script-1.13.jar".

Is there a proper way to do this? In my projects module-info, or through maven? Without having to manually alter the jar?

Thanks in advance!

If relevant:
Mac OS, Java openjdk-14.0.2, Maven 3.6.3, VSCode 1.49.0

TL;DR — There is no way to circumvent the batik library's java.lang.module.InvalidModuleDescriptorException issue using the JPMS system.

The long-winded version

I came across the same issue myself some months ago. I found, like you more than likely also found, this old Jigsaw Dev mailing list post…

>> …
>>
>> > 2) Error occurred during initialization of boot layer
>>
>> > java.lang.module.FindException: Unable to derive module descriptor for
>>
>> > .m2\repository\org\apache\xmlgraphics\batik-script\1.8\batik-script-1.8.jar
>>
>> > Caused by: java.lang.module.InvalidModuleDescriptorException: Provider
>>
>> > class org.apache.batik.bridge.RhinoInterpreterFactory not in module
>>
>>
>> There exists META-INF/services/org.apache.batik.script.InterpreterFactory config file with a provider class that is not in this module.
>>
>> …

The person replying to the OP there is a member of the Java Platform Development Team that has decades of experience.

I interpreted their „I suggest you contact the maintainer of this library to publish a version that can be run as a module“ advice to the mailing list OP, as a clue that trying to use the batik library with JPMS is hopeless.

I was battling this for quite a while, before finally giving up JPMS and trying to circumvent the system by automating the JAR-alterations I had gotten working.

By using a Maven plugin called Truezip I set up Maven to automatically unzip, alter and then rezip the dependency. Even though it's not the most elegant solution, it works, and I'm also using it on another dependency with a similar issue.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>truezip-maven-plugin</artifactId>
    <version>1.2</version>
    <executions>
        <execution>
            <id>fix-batik-script</id>
            <goals>
                <goal>remove</goal>
            </goals>
            <phase>process-resources</phase>
            <configuration>
                <fileset>
                    <directory>${settings.localRepository}/org/apache/xmlgraphics/batik-script/1.13/batik-script-1.13.jar/META-INF/services</directory>
                    <includes>
                        <include>org.apache.batik.script.InterpreterFactory</include>
                    </includes>
                </fileset>
            </configuration>
        </execution>
    </executions>
</plugin>