Обход старой метаинформации/сервисов Java при использовании модулей Java

Я пытаюсь создать приложение Java FX, показывающее SVG-изображение, используя Batik-library, но У меня проблемы с правильным импортом всех компонентов.

Примерно через 5 часов поиска и тестирования я, наконец, изменил один из jar-файлов зависимостей, чтобы удалить старую службу Java (или как вы ее называете), которая предшествует текущей модульной системе. Таким образом, текущий обходной путь заключается в ручном удалении файла META-INF/services/org.apache.batik.script.InterpreterFactory в batik-script-1.13.jar.

Есть ли правильный способ сделать это? В моих проектах модуль-информация или через maven? Без необходимости вручную переделывать банку?

Заранее спасибо! :)

Если применимо: Mac OS, Java openjdk-14.0.2, Maven 3.6.3, VSCode 1.49.0


person RandomDude244    schedule 15.09.2020    source источник
comment
Этот вопрос лучше задать владельцам библиотеки.   -  person Naman    schedule 16.09.2020
comment
Правда, мой вопрос больше направлен на то, есть ли способ сделать это через JPMS-систему. Учитывая, что она, насколько я понимаю, действительно пытается поддерживать старые JAR, создавая автоматические модули. Я думаю, что есть способ справиться с этим.   -  person RandomDude244    schedule 16.09.2020


Ответы (2)


TL;DR. Невозможно обойти проблему с библиотекой батика java.lang.module.InvalidModuleDescriptorException с помощью системы JPMS.


Длинная версия

Я сам столкнулся с той же проблемой несколько месяцев назад. Я обнаружил, как и вы, скорее всего, также нашел эта старая запись списка рассылки Jigsaw Dev

2) Ошибка при инициализации загрузочного слоя

java.lang.module.FindException: невозможно получить дескриптор модуля для

.m2\repository\org\apache\xmlgraphics\batik-script\1.8\batik-script-1.8.jar

Вызвано: java.lang.module.InvalidModuleDescriptorException: Provider

класс org.apache.batik.bridge.RhinoInterpreterFactory отсутствует в модуле

Существует файл конфигурации META-INF/services/org.apache.batik.script.InterpreterFactory с классом поставщика, которого нет в этом модуле.

Человек, отвечающий на OP, является членом группы разработчиков платформы Java, который имеет многолетний опыт.

Я истолковал их совет «Я предлагаю вам связаться с сопровождающим этой библиотеки, чтобы опубликовать версию, которую можно запустить как модуль» в списке рассылки OP, как подсказку, что попытка использовать библиотеку batik с JPMS безнадежна.

person deduper    schedule 04.10.2020

Я довольно долго боролся с этим, пока, наконец, не отказался от JPMS и не попытался обойти систему, автоматизировав JAR-изменения, которые я заставил работать.

Используя подключаемый модуль Maven под названием Truezip, я настроил Maven для автоматического распаковывания, изменения и повторного архивирования зависимости. Несмотря на то, что это не самое элегантное решение, оно работает, и я также использую его для другой зависимости с похожей проблемой.

<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>
person RandomDude244    schedule 05.10.2020
comment
Это ужасная работа вокруг! Но спасибо за код. - person Lii; 04.05.2021