GWT и SpringBoot — есть ли разумный способ справиться с конфликтующими зависимостями?

Выясните, где находится транзитивная зависимость, которую вы хотите исключить при компиляции кода GWT.

    <dependency>
        <groupId>spring-dependency-with-hibernate</groupId>
        <artifactId>some-spring-boot-starter</artifactId>
        <exclusions>
            <exclusion>
               <groupId>org.hibernate</groupId>
               <artifactId>hibernate-validator</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Таким образом, во время выполнения будет доступна только версия hibernate, предоставленная GWT.

Да, то, что я хотел сделать, на самом деле можно сделать, хотя и не тривиально... совсем нет.

Чтобы настроить многомодульный pom maven, который можно продуктивно использовать в том смысле, что вы можете получить обмен кодом как для внутреннего, так и для внешнего кода без необходимости выбирать зависимости валидатора gwt или зависимости валидатора springboot, по сути, я организую мой проект следующим образом.

У вас есть:

LEVEL 1: myproject-root
----- LEVEL 2: myproject-backend
---------- LEVEL 3: myproject-backend-api
---------- LEVEL 3: myproject-backend-impl
------ LEVEL 2: myproject-frontend
------ LEVEL 2: myproject-runner
-----------LEVEL 3: myproject-runner-jar
-----------LEVEL 3: myproject-runner-war

В myproject-root вы, естественно, объявляете подмодули. Вы управляете зависимостями некоторых безобидных плагинов, таких как плагин surefire. Вы управляете исходным кодом Java и целевым языком компиляции. Вы делаете очень немного больше, чем это. Если у вас есть какие-то плагины, которые вы можете настраивать перекрестно, вы можете поместить их в управление плагинами.

В myproject-backend вы, по сути, наследуете зависимости Springboot от управления зависимостями, добавляя к управлению зависимостями:

<dependencyManagement>
        <dependencies>
            <!-- Inherit dependencies from spring boot dependency management pom -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-parent</artifactId>
                <version>${version.spring.boot}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

Вы объявляете два подмодуля и уходите. Вы не объявляете здесь никаких перекрестных зависимостей. Вы используете только управление зависимостями. Интерфейсный компонент будет обращаться к подмодулю API, и вы не хотите создавать магнит зависимостей во внутреннем pom, поэтому здесь вы максимально консервативны.

В myproject-backend-api вы начинаете с того, что позволяете этому подмодулю быть подмодулем jar. В дальнейшем вы захотите разветвить API-компонент дальше, разделив API-интерфейсы по характеру точки входа. Начнем с того, что компонент -api будет иметь API, необходимый для связи между сервером и внешним интерфейсом, что-то вроде «общего» в документации. Здесь вы максимально осторожны, чтобы иметь как можно меньше элементов в элементе зависимостей. Внешний интерфейс будет использовать эти API, и вы не хотите, чтобы ваш пакет API зависел от каких-либо API весенней загрузки.

В backend-impl вы пишете свою фактическую бизнес-логику, и вы можете свободно зависеть от полного стека загрузки Spring. Правило таково: следите за тем, чтобы никто никогда не указывал на этот магнит зависимостей, особенно никогда не позволяйте компоненту gwt даже почувствовать запах существования библиотек Springboot. Не обращайтесь к нему никогда.

В myproject-frontend вы не разветвляете его на разные подмодули, как вы могли бы сделать с компонентом API. Здесь вы создаете монолитный компонент для кода gwt, чтобы вам было проще заставить плагин gwt maven работать на вас, выполняя перекомпиляцию горячего кода. В этом компоненте вы зависите от myproject-api, а также от любой соответствующей библиотеки gwt, такой как gwt-user, валидатор гибернации со старой версией, необходимой gwt, и т. д. Правило для myproject-frontend состоит в том, чтобы объявить каждая отдельная зависимость в компоненте как необязательная. Вы не хотите принимать какие-либо транзитивные зависимости от компонента. В производственной среде все, что вам нужно, это myproject-frontend.jar/META-INF/resources/MyProjectModule.html... И все такие статические ресурсы, которые Springboot должен будет обнаруживать и обслуживать. Однако пока вы находитесь в режиме разработки, то, что вы хотите сделать в этом внешнем компоненте, это: (а) настроить ваш gwt-плагин, чтобы он не запускал сервер причала

<noServer>true</noServer>

Дело в том, что если запустить этот сервер причала, единственное, что он будет иметь в своем пути к классам, будет код внешнего интерфейса и API, а определенно не код внедрения. И во-вторых, вы не хотите использовать причал gwt, вы либо хотите использовать tomcat springboot, либо причал springboot. Гораздо лучше использовать встроенные контейнеры Springboot с соответствующими библиотеками веб-сокетов и тому подобное.

(b) С помощью Springboot вы хотите серверировать свои статические ресурсы из META-INF/resources/ или общей папки. Я предпочитаю ресурсы, так как это было бы там, где вы обычно размещаете компоненты JSF. В любом случае, поскольку место, откуда берутся статические ресурсы, особенное, вы хотите настроить свой плагин gwt для компиляции исходных кодов Java в папку записи.

<webappDirectory>${project.build.directory}/classes/META-INF/resources</webappDirectory>

Итак, что-то вроде выше.

Наконец, и это было моей главной ошибкой, вы не запускаете свой код там, где вы пишете свой интерфейсный код. Это неправильно, потому что это заставляет ваш интерфейсный код нуждаться в зависимостях Springboot, что причинит вам сильную боль из-за конфликтующих библиотек.

Итак, чтобы избежать этой проблемы, вы создаете компонент myproject-runner, и если вы хотите быть очень подробным, вы делаете его родительским компонентом pom, чтобы вы могли разветвить свою упаковку либо на jar, либо на war. Лично мне исполняемый jar нравится гораздо больше, чем военный вариант. Я никогда не захочу развертывать приложение sprintboot в чем-то вроде тяжелой веб-логики ... но что бы ни раскачивало вашу лодку.

В любом случае, Spring Boot Runner — это ваша конечная зависимость magenet. Этот компонент будет зависеть от каждого модуля, который у вас есть, и от их транзитивных зависимостей. Но поскольку вы отделяете свой компонент бегуна от внешнего кода и делаете все зависимости во внешнем коде опциональными... Ну, по сути, вы связываете только springboot и ваши статические ресурсы gwt.

Пока вы развиваетесь, то, что вы делаете, это... как только вы это узнаете... просто. (A) вы запускаете приложение spring boot jar, запуская основной файл. Если вы действительно хотите развернуть военный файл, это ваш выбор, вы также можете создать военный файл и развернуть его на коте или что-то еще...

(b) вы переходите к компоненту внешнего интерфейса, щелкаете его правой кнопкой мыши, выбираете запуск как Maven Build и gwt:run. Запуск gwt запустит сервер кода gwt, который будет полностью слеп к вашему внутреннему коду, единственное, что он увидит перед глазами, это код, который есть у вас во внешнем компоненте, а также все ваши зависимости от gwt. добавлено как необязательное.

Наконец-то вы можете выполнять горячую замену кода в бэкэнде, если используете Springboot dev. Наконец-то вы можете «горячую» замену кода в этом монолитном внешнем компоненте, как только вы запустите плагин gwt.

Вывод, это возможно, но это адский беспорядок. Рад, что эта проблема ушла.

Я полагаю, что у меня были похожие проблемы, и я обнаружил следующее при использовании Eclipse IDE, GWT Google Plugin, SpringBoot и Maven. Рецепт не простой, но он сработал для моей команды.

GWT-dev и сервер Jetty не работают с SpringBoot. Вы должны исправить путь к классам из-за жестко запрограммированных зависимостей Jetty и gwt-dev, будут работать только те зависимости, против которых были созданы gwt-dev и Jetty.

Мне пришлось разделить проект пользовательского интерфейса GWT на два артефакта Maven. Одним из артефактов было веб-приложение, способное работать только в Eclipse, при этом все библиотеки SpringBoot были исключены из пути к классам. Другим артефактом был развертываемый JAR-файл SpringBoot с типом упаковки maven «war» и наложением WAR на специальный артефакт Eclipse, включающий только специфический контент GWT.

надеюсь, это поможет