spring-boot-devtools перезагружает многомодульные изменения проекта maven

Перезагрузка изменений многомодульного проекта maven

Параметр

Представьте многомодульный maven-проект. Структура проекта такова:

pom.xml //parentpom
   |
  pom.xml //submodule_1
   |
  pom.xml //submodule_2
   .
   .
   .
  pom.xml //submodule_7

Например, submodule_5 имеет submodule_6 и submodule_7 в качестве зависимостей. Submodule_5 может быть создан для создания War-файла, который можно развернуть. Spring-Boot-Devtools обеспечивает функцию автоматического перезапуска при изменении submodule_5 его пути к классам.

Всякий раз, когда приложение запускается с использованием:

mvn spring-boot:run

И изменения вносятся в submodule_5 (в зависимости от того, какую IDE вы используете, путь к классам изменяется. (для Eclipse автоматически / для InteliJ при нажатии Ctrl+ F9)) spring-boot автоматически перезапускает приложение и добавляются изменения. Изменения, происходящие с субмодулем_6 или субмодулем_7, не вызывают автоматический перезапуск.

Вопросы

  1. Есть ли способ сделать так, чтобы всякий раз, когда вы вносите изменения в submodule_6 или submodule_7, они принудительно перезапускали и для этого применяли изменения?
  2. Spring-boot-devtools использует два загрузчика классов: «Базовый загрузчик классов» и «Загрузчик классов перезапуска». Это так, что при первоначальном запуске приложения submodule_6 и submodule_7 добавляются в «Базовый загрузчик классов», а submodle_5 сохраняется в «Перезапускающем загрузчике классов»? Сделать так, чтобы каждый раз, когда submodule_5 принудительно перезапускал, он использовал версии submodule_6 и submodule_7 из «Базового загрузчика классов»?

spring-boot java maven spring spring-boot-maven-plugin
person Nodon Darkeye    schedule 17.08.2016    source источник
comment
Ответ на StackOverflow не работает таким образом, когда кто-то дает вам правильный ответ, вы можете просто проверить это, и он появится сверху с правильной пометкой. Посмотреть другие вопросы   -  person Paolo Forgia    schedule 17.08.2016

Ответы (3)


arrow_upward
5
arrow_downward

Вы можете указать дополнительные папки для просмотра spring-boot-devtools в application.properties:

spring.devtools.restart.additional-paths=../submodule_6,../submodule_7

См. документацию Spring по использование-boot-devtools-restart-дополнительных-путей.

person alexbt    schedule 17.08.2016
comment
Я тоже наткнулся на это. Мой вопрос по этому поводу будет заключаться в том, есть ли способ сделать это с помощью аннотаций или чего-то в этом роде. И если перезапуск срабатывает, я предполагаю, что это зависит только от того, насколько хорошо maven и т. д. настроен также на сборку submodule_6 и submodule_7 всякий раз, когда submodule_5 перезапускается? - person Nodon Darkeye; 17.08.2016
comment
Только что попробовал, и это работает! Я считаю, что причина, по которой это работает, заключается в том, что spring-boot:run считывает скомпилированные классы и ресурсы непосредственно из папок проектов (а не сгенерированные артефакты). Добавил папку чужого модуля в отслеживаемую папку. Я изменил класс в этом другом модуле, приложение перезапустилось, и я увидел изменение. - person alexbt; 17.08.2016
comment
Я тоже пробовал и у меня перезагрузка происходит, но изменения не применяются. Я читал, что работа из командной строки и из IDE может отличаться. Могу я спросить, как вы запустили свое приложение, я сделал это из командной строки. Он обнаружил, что были внесены изменения. Он перезапустил приложение, но не применил изменения. Возможно, это работает по-разному, когда вы работаете в среде IDE. - person Nodon Darkeye; 18.08.2016
comment
Я сделал это из Eclipse, который успел пересобрать модифицированный .java в *.class до того, как произойдет перезапуск - person alexbt; 18.08.2016

arrow_upward
4
arrow_downward

Чтобы решить эту проблему, я запустил приложение из InteliJ. без добавления.

spring.devtools.restart.additional-paths=../submodule_6,../submodule_7

IntelliJ и spring-boot очень хорошо работают вместе. Причина, по которой он не работал у меня, заключалась в том, что сначала я работал из командной строки.

Разница между командной строкой и IDE

Таким образом, spring-boot-devtools использует два загрузчика классов для загрузки приложения. Банки будут загружены единицы в «базовом загрузчике классов», ваше приложение будет загружено в «перезапуске загрузчика классов». Этот последний загрузчик классов будет перезапускаться каждый раз при изменении пути к классам.

Всякий раз, когда вы запускаете submodule_5 из командной строки, он будет создавать submodule_6 и submodule_7 и добавлять jar-файлы в сборку submodule_5. Всякий раз, когда в submodule_6 и submodule_7 вносятся изменения, spring-boot даже не заметит, так как он только наблюдает за submodule_5 и имеет необходимые ему jar-файлы. Даже если вы специально скажете ему также следить за этими подмодулями, он все равно не будет их перестраивать, он просто продолжит использовать банки, которые он уже загрузил в «базовом загрузчике классов» (это мое предположение, я не 100 % уверены в том, как это работает).

Всякий раз, когда вы запускаете submodule_5 из IDE, он не создает jar для submodule_6 и submodule_7. Он просто будет использовать их путь к классам. Это делает так, что изменения во всем пути к классам вашего проекта (все подмодули) вызовут автоматический перезапуск, и изменения будут применены.

ДОПОЛНИТЕЛЬНО

Всякий раз, когда вы запускаете из IDE изменения на такие ресурсы, как html-файлы, css-файлы, xml-файлы. . . не вызовет перезагрузку, так как это не изменение пути к классам. Но изменения все равно будут видны.

person Nodon Darkeye    schedule 19.08.2016

arrow_upward
0
arrow_downward

Я пробовал с spring.devtools.restart.additional-paths и в любом случае это бесполезно: изменение источника перезапускает приложение, но беспомощно, потому что приложение не имеет цели/классов модулей во время его выполнения.

С spring-boot:run, выполненным в самых последних версиях IntelliJ: он работает из коробки.

С spring-boot:run, выполненным в командной строке: есть как минимум два случая.

Случай 1) мы хотим выполнить spring-boot:run из модуля, имеющего основной класс весенней загрузки (submodule_5 в оп-вопросе). Нам нужно добавить в конфигурацию плагина его pom.xml дополнительные пути к классам скомпилированных классов, которые мы хотим, чтобы плагин весенней загрузки знал об этом:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>                    
                <folders>
                    <folder>                            
                           ../submodule_6/target/classes
                    </folder>
                    <folder>                            
                           ../submodule_7/target/classes
                    </folder>
                </folders>
            </configuration>
        </plugin>
    </plugins>
</build>

Случай 2) мы хотим выполнить spring-boot:run из родительского модуля.
Это работает только с мультимодулями pom, которые также являются родительскими модулями.
Нам нужно сделать два изменения:
Во-первых, добавьте объявление плагина весенней загрузки с флагом skip в родительском pom:

 `<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
                <skip>true</skip>
            </configuration>
        </plugin>

    </plugins>
 </build>`

Затем добавьте в pom.xml модуль с основным классом весенней загрузки (submodule_5 в оп-вопросе):

 <build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
                <skip>false</skip>                 
            </configuration>
        </plugin>
    </plugins>
</build>

Теперь мы можем запустить приложение из родительского pom с помощью:

mvn -pl submodule_5 -am spring-boot:run

К вашему сведению, эти флаги maven указывают на применение цели к submodule_5 после применения ее к его зависимостям (тогда как флаг пропуска в multi/parent pom.xml).

person davidxxx    schedule 24.04.2021