Проект GWT (Maven): конфликт зависимостей

У меня есть проект GWT со следующими зависимостями

    <dependency>
        <groupId>com.google.gwt.inject</groupId>
        <artifactId>gin</artifactId>
        <version>2.1.2</version>
    </dependency>

    <dependency>
        <groupId>net.sourceforge.owlapi</groupId>
        <artifactId>owlapi-distribution</artifactId>
        <version>4.0.2</version>
    </dependency>

  • gin 2.1.2 зависит от guice 3.0, а owlapi 4.0.2 зависит от guice 4.0-beta.

  • gin используется на стороне клиента, а owlapi — на стороне сервера.

  • Компиляция завершается ошибкой, когда я принудительно использую guice 4.0-beta. Вызвано java.lang.ClassNotFoundException: com.google.inject.internal.util.$Maps

  • Компиляция завершается успешно, когда я принудительно использую guice 3.0, но происходит сбой во время выполнения из-за java.lang.ClassNotFoundException: com.google.inject.internal.guava.collect.$ImmutableList

  • Понижение версии owlapi не вариант.

Какие варианты у меня есть, чтобы сделать эту работу? Могу ли я каким-то образом использовать области зависимостей, сохраняя при этом функционирующий GWT DevMode?


maven guice gwt owl-api gwt-gin
person hansi    schedule 28.05.2015    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Разделите проект на отдельные модули. Учитывая ограниченные (изначально разработанные) параметры области действия зависимостей Maven, это действительно правильный путь.

Используйте один модуль для клиентского кода, используя только клиентские зависимости (GIN с Guice 3), и один модуль для серверного кода, используя только серверные зависимости (OWLAPI с Guice 4); и пусть ваш клиентский модуль скомпилирует ваш код в JS и упакует их как WAR, который вы можете использовать в качестве «наложения» в серверном модуле (или, возможно, использовать третий модуль, который зависит как от клиента, так и от сервера, если вы предпочитаете). Если у вас есть общий код, используйте третий/четвертый общий модуль, от которого зависят и клиентский, и серверный модули; общий модуль будет вызывать цель jar-no-fork maven-source-plugin, чтобы клиентский модуль мог зависеть от общих источников.

Вы можете найти архетипы, соответствующие этому подходу, по адресу https://github.com/tbroyer/gwt-maven-archetypes. . Они используют мой плагин Maven для GWT, но более ранние версии (вам придется клонировать и mvn install проект затем из соответствующей фиксации) полагался на плагин Maven от Mojo для GWT (мой плагин разработан с учетом многомодульных проектов и удалил множество хаков, которые были необходимы ранее при использовании плагина Mojo).

person Thomas Broyer    schedule 29.05.2015
comment
Смогу ли я каким-то образом использовать DevMode, когда мой клиентский модуль скомпилирован в JS? - person hansi; 30.05.2015
comment
Прочтите README для моих архетипов, там все объяснено. TL;DR: да. - person Thomas Broyer; 30.05.2015

arrow_upward
1
arrow_downward

Это сложный сценарий для моего опыта работы с maven с областями для зависимостей.

Учитывая, что в полученной вами ошибке упоминается гуава, вам может повезти, если вы заставите использовать последнюю гуаву — owlapi должен работать с 17 или 18.

Другим вариантом может быть попытка перекомпилировать gin с помощью guice 4 (и, возможно, внести изменения выше по течению). Я понятия не имею, насколько это может быть тяжело. Вы также должны убедиться, что ваши моментальные снимки выпущены вместе с вашим приложением и доступны для других членов вашей команды, которым они могут понадобиться.

person Ignazio    schedule 29.05.2015

arrow_upward
0
arrow_downward

Для чего это стоит. Я потратил несколько минут и «портировал» его на guice 4.0. К счастью, это было довольно легко. Я его усердствовал, в противном случае изменений в кодовой базе практически не было.

https://github.com/chinshaw/google-gin

person Chris Hinshaw    schedule 10.02.2016