Как создать многомодульный проект maven

многомодульный Maven проект

Возникла такая проблема при создании проекта Maven с несколькими дочерними модулями. Имеется структура:

├─── Root │ ├─── Engine │ ├─── Mod1 │ ├─── Mod2

Root — Корневой Pom проекта
Engine — набор интерфейсов и абстрактных классов
Mod1 — реализация интерфейсов и классов под одни задачи
Mod2 — реализация интерфейсов и классов под другие задачи

При этом у Mod1 и Mod2 есть свои внутренние, отдельные друг от друга зависимости к нужным им библиотекам.

По поводу структуры, возможно вопрос не стоит (если только с ней не связано решение), у всех модулей прописан общий на Root , а в нем эти же модули прописаны вот так:

 Engine Mod1 Mod2

Также к Mod1 и Mod2 модуль Engine подключен как

Прикол в том, что по итогу мне нужно получить два .jar файла которые НЕ содержат ВСЕХ зависимостей, но каждый из них содержит Engine и конкретную реализацию, т.е. типа таких 2 файла:

├─── Jar1.jar │ ├─── Engine │ ├─── Mod1 ├─── Jar2.jar │ ├─── Engine │ ├─── Mod2

Зависимости самих реализаций вообще никак не трогая, они тут нужны для разработки, а там где проект будет запускаться они уже подключены.

Может кто подсказать как это сделать? Увы на запросы в гугле постоянно находится «сборка многомодульного webapp через maven», но там не подходит решение, т.к. у меня всё-таки не веб-приложение

Многомодульный проект с Maven

В этом руководстве мы узнаем, как создать многомодульный проект с помощью Maven.

Сначала мы обсудим, что такое многомодульный проект, и рассмотрим преимущества такого подхода. Затем мы настроим наш образец проекта. Для хорошего знакомства с Maven ознакомьтесь с этим руководством .

2. Многомодульный проект Maven

Многомодульный проект создается из POM-агрегатора, который управляет группой подмодулей. В большинстве случаев агрегатор находится в корневом каталоге проекта и должен иметь упаковку типа pom .

Подмодули представляют собой обычные проекты Maven, и их можно создавать отдельно или с помощью агрегатора POM.

При построении проекта с помощью POM-агрегатора каждый проект с типом упаковки, отличным от pom , приведет к построению архивного файла.

3. Преимущества использования мультимодулей

Существенным преимуществом использования этого подхода является то, что мы можем уменьшить дублирование.

Допустим, у нас есть приложение, состоящее из нескольких модулей, внешнего модуля и внутреннего модуля. Теперь представьте, что мы работаем над ними и меняем функциональность, которая влияет на них обоих. В этом случае без специализированного инструмента сборки нам пришлось бы собирать оба компонента по отдельности или писать скрипт для компиляции кода, запуска тестов и отображения результатов. Затем, когда мы получили еще больше модулей в проекте, им стало сложнее управлять и поддерживать.

В реальном мире проектам могут потребоваться определенные подключаемые модули Maven для выполнения различных операций в течение жизненного цикла сборки , для совместного использования зависимостей и профилей, а также для включения других проектов BOM .

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

4. Родительский POM

Maven поддерживает наследование таким образом, что каждый файл pom.xml имеет неявный родительский POM. Он называется Super POM и может быть расположен в двоичных файлах Maven. Эти два файла объединяются Maven и образуют эффективный POM.

Мы можем создать собственный файл pom.xml, который будет служить нам родительским проектом . Затем мы можем включить в него всю конфигурацию с зависимостями и установить его как родительский для наших дочерних модулей, чтобы они наследовали от него.

Помимо наследования, Maven предоставляет понятие агрегации. Родительский POM, использующий эту функциональность, называется агрегатным POM . По сути, этот тип POM явно объявляет свои модули в файле pom.xml.

5. Подмодули

Подмодули или подпроекты — это обычные проекты Maven, которые наследуются от родительского POM. Как мы уже знаем, наследование позволяет нам делиться конфигурацией и зависимостями с подмодулями. Однако, если мы хотим собрать или выпустить наш проект за один раз, мы должны явно объявить наши подмодули в родительском POM. В конечном счете, наш родительский POM будет родителем, а также совокупным POM.

6. Создание приложения

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

Это приложение будет состоять из трех модулей, которые будут представлять:

Основная часть нашего домена
Веб- служба, предоставляющая некоторые REST API .
Веб — приложение , содержащее какие-либо веб-ресурсы, ориентированные на пользователя.

Поскольку мы сосредоточимся на Maven, реализация этих сервисов останется неопределенной.

6.1. Создание родительского POM

Во-первых, давайте создадим родительский проект :

mvn archetype:generate -DgroupId=com.foreach -DartifactId=parent-project

После того, как родитель сгенерирован, мы должны открыть файл pom.xml , расположенный в каталоге родителя, и добавить упаковку как pom :

 packaging>pompackaging>

Установив для упаковки тип pom , мы заявляем, что проект будет служить родителем или агрегатором; он не будет производить дальнейших артефактов.

Теперь, когда наш агрегатор готов, мы можем сгенерировать наши подмодули.

Однако мы должны отметить, что именно здесь находится вся конфигурация для совместного использования, которая в конечном итоге будет повторно использоваться в дочерних модулях. Помимо прочего, мы можем использовать здесь dependencyManagement или pluginManagement .

6.2. Создание подмодулей

Поскольку наш родительский POM был назван parent-project , нам нужно убедиться, что мы находимся в родительском каталоге, и запустить команды генерации :

cd parent-project mvn archetype:generate -DgroupId=com.foreach -DartifactId=core mvn archetype:generate -DgroupId=com.foreach -DartifactId=service mvn archetype:generate -DgroupId=com.foreach -DartifactId=webapp

Обратите внимание на используемую команду. Это то же самое, что мы использовали для родителя. Дело в том, что эти модули являются обычными проектами Maven, но Maven распознал их вложенность. Когда мы изменили каталог на parent-project , он обнаружил, что у родителя есть упаковка типа pom, и он соответствующим образом изменит файлы pom.xml .

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

 modules>   module>coremodule>   module>servicemodule>   module>webappmodule>   modules>

а в pom.xml отдельных подмодулей он добавит родительский проект в родительский раздел:

 parent>   artifactId>parent-projectartifactId>   groupId>com.foreachgroupId>   version>1.0-SNAPSHOTversion>   parent>

Затем Maven успешно сгенерирует три подмодуля.

Важно отметить, что подмодули могут иметь только одного родителя. Однако мы можем импортировать множество спецификаций. Подробнее о файлах BOM можно прочитать в этой статье .

6.3. Создание проекта

Теперь мы можем собрать все три модуля одновременно. В каталоге родительского проекта мы запустим:

mvn package

Это соберет все модули. Мы должны увидеть следующий вывод команды:

[INFO] Scanning for projects. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] parent-project [pom] [INFO] core [jar] [INFO] service [jar] [INFO] webapp [war] . [INFO] Reactor Summary for parent-project 1.0-SNAPSHOT: [INFO] parent-project . SUCCESS [ 0.272 s] [INFO] core . SUCCESS [ 2.043 s] [INFO] service . SUCCESS [ 0.627 s] [INFO] webapp . SUCCESS [ 0.572 s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------

Reactor перечисляет parent-project , но, поскольку он имеет тип pom , он исключается, и в результате сборки создаются три отдельных файла .jar для всех остальных модулей. При этом сборка происходит в трех из них.

Более того, Maven Reactor проанализирует наш проект и соберет его в нужном порядке. Поэтому, если наш модуль веб -приложения зависит от модуля службы , Maven сначала создаст службу , а затем веб- приложение .

6.3. Включить управление зависимостями в родительском проекте

Управление зависимостями — это механизм централизации информации о зависимостях для многомодульного родительского проекта и его дочерних элементов.

Если у вас есть набор проектов или модулей, которые наследуют общего родителя, вы можете поместить всю необходимую информацию о зависимостях в общий файл pom.xml . Это упростит ссылки на артефакты в дочерних POM .

Давайте взглянем на образец pom.xml родителя :

 dependencyManagement>   dependencies>   dependency>   groupId>org.springframeworkgroupId>   artifactId>spring-coreartifactId>   version>5.3.16version>   dependency>   //.   dependencies>   dependencyManagement>

Объявив версию spring-core в родительском элементе, все подмодули, которые зависят от spring-core , могут объявить зависимость, используя только groupId и артефактId , и версия будет унаследована:

 dependencies>   dependency>   groupId>org.springframeworkgroupId>   artifactId>spring-coreartifactId>   dependency>   //.   dependencies>

Кроме того, вы можете указать исключения для управления зависимостями в родительском pom.xml , чтобы определенные библиотеки не наследуются дочерними модулями:

 exclusions>   exclusion>   groupId>org.springframeworkgroupId>   artifactId>spring-contextartifactId>   exclusion>   exclusions>

Наконец, если дочернему модулю необходимо использовать другую версию управляемой зависимости, вы можете переопределить управляемую версию в дочернем файле pom.xml :

 dependency>   groupId>org.springframeworkgroupId>   artifactId>spring-coreartifactId>   version>4.3.30.RELEASEversion>   dependency>

Обратите внимание, что в то время как дочерние модули наследуются от своего родительского проекта, родительский проект не обязательно имеет какие-либо модули, которые он объединяет. С другой стороны, родительский проект может также объединять проекты, которые не наследуются от него.

Дополнительные сведения о наследовании и агрегации см. в этой документации .

6.4. Обновление подмодулей и сборка проекта

Мы можем изменить тип упаковки каждого субмодуля. Например, давайте изменим упаковку модуля webapp на WAR , обновив файл pom.xml :

 packaging>warpackaging>

и добавление maven-war-plugin в список плагинов:

 build>   plugins>   plugin>   groupId>org.apache.maven.pluginsgroupId>   artifactId>maven-war-pluginartifactId>   version>3.3.2version>   configuration>   failOnMissingWebXml>falsefailOnMissingWebXml>   configuration>   plugin>   plugins>   build>

Теперь мы можем протестировать сборку нашего проекта с помощью команды mvn clean install . Вывод журналов Maven должен быть примерно таким:

[INFO] Scanning for projects. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] parent-project [pom] [INFO] core [jar] [INFO] service [jar] [INFO] webapp [war]

//. [INFO] Reactor Summary for parent-project 1.0-SNAPSHOT: [INFO] [INFO] parent-project . SUCCESS [ 0.272 s] [INFO] core . SUCCESS [ 2.043 s] [INFO] service . SUCCESS [ 0.627 s] [INFO] webapp . SUCCESS [ 1.047 s]

7. Заключение

В этой статье мы обсудили преимущества использования мультимодулей Maven. Мы также различали обычный родительский POM Maven и совокупный POM. Наконец, мы рассмотрели, как настроить простой мультимодуль, с которым можно начать играть.

Maven — отличный инструмент, но он сложен сам по себе. Если мы хотим узнать больше подробностей о Maven, мы можем посмотреть справочник по Sonatype Maven или руководства по Apache Maven . Если мы ищем расширенные возможности использования многомодульной настройки Maven, мы можем посмотреть , как проект Spring Boot использует ее использование .

Все примеры кода, использованные в этой статье, доступны на Github .

1. Обзор
2. Многомодульный проект Maven
3. Преимущества использования мультимодулей
4. Родительский POM
5. Подмодули

6. Создание приложения

6.1. Создание родительского POM
6.2. Создание подмодулей
6.3. Создание проекта
6.3. Включить управление зависимостями в родительском проекте
6.4. Обновление подмодулей и сборка проекта

Многомодульный maven проект

Maven позволяет собирать проект из нескольких модулей. Каждый программный модуль включает свой проектный файл pom.xml. Один из проектных pom.xml файлов является корневым. Корневой pom.xml позволяет объединить все модули в единый проект. При этом в корневой проектный файл можно вынести общие для всех модулей свойства. А каждый модульный pom.xml должен включать параметры GAV (groupId, artifactId, version) корневого pom.xml.

Общие положения разработки многомодульного maven-приложения рассмотрены на странице Наследование проектов в maven. В данной статье рассмотрим пример сборки многомодульного приложения. В качестве «подопытного» приложения используем пример, представленный на странице Pluggable решение. На выходе данного примера мы должны получить 3 архивных и один исполняемый jar-файлов. Главный исполняемый jar-модуль динамически «при необходимости» загружает остальные архивные jar’ники. Данный «подопытный» пример был использован для «оборачивания» jar’ника в exe-файл с использованием maven-плагина launch4j.

Описание многомодульного проекта

На скриншоте представлена структура проекта pluggable, включающая следующие проектные модули :

• hello-plugin1	– динамически загружаемый плагин №1 (hello1.jar);
• hello-plugin2	– динамически загружаемый плагин №2 (hello2.jar);
• plugin-api	– интерфейсы описания плагинов (plugin-api.jar);
• plugin-loader	– главный исполняемый jar модуль.

Дополнительные поддиректории проекта, используемые для размещения jar-модулей :

• commons	– поддиректория размещения архивного jar-модуля описания интерфейса плагинов;
• plugins	– поддиректория размещения jar-модулей (плагинов);

Главный исполняемый модуль plugin-loader.jar размещается в корневой директории проекта, где размещается и проектный/корневой pom.xml. Файл run.bat можно использовать для старта plugin-loader.jar из консоли в Windows.

Примечание : в исходные коды классов внесены изменения, связанные с из размещением в пакетах. В исходном примере все классы располагаются в «корне».

Начнем рассмотрение примера с корневого многомодульного pom.xml.

Листинг многомодульного корневого pom.xml

Корневой pom.xml включает параметры GAV (groupId, artifactId, Version), общую для всех модулей проекта секцию и секцию описания модулей . Обратите внимание на атрибут packaging>, значение которого должно быть «pom».

Следует отметить, что порядок включения программных модулей проекта составлен таким образом, что сначала представлены исполняемый модуль plugin-loader.jar и плагины (hello-plugin1.jar, hello-plugin2.jar), после чего следует интерфейсный модуль plugin-api.jar. Если собирать проект по-отдельности, то модуль plugin-api.jar должен быть собран в первую очередь и размещен в репозитории командой «mvn install». В этом случае зависимые модули plugin-loader.jar и плагины (hello-plugin1, hello-plugin2) собрались бы нормально. Ну, а мы в этом примере посмотрим, как поступит Maven в случае, если порядок описания модулей для сборки «нарушен».

 4.0.0 ru.pluggable.main pluggable pom 1.0.0 MultiModule application true 1.8 1.8 1.8 UTF-8  plugin-loader hello-plugin1 hello-plugin2 plugin

Модуль описания интерфейсов плагинов plugin-api.jar

На следующем скриншоте представлена структура проекта plugin-api. Интерфейсные классы Plugin, PluginContext располагаются в пакете «ru.plugin».

Листинг pom.xml

Проектный pom.xml модуля plugin-api.jar включает GAV-параметры, секцию описания родительского GAV () и секцию сборки , где в качестве выходной директории размещения () указана поддиректория «$/../commons».

 4.0.0 ru.pluggable plugin-api jar 1.0.0 Plugin API ru.pluggable.main pluggable 1.0.0  $   org.apache.maven.plugins maven-jar-plugin 2.3.1  $/../commons

Модуль описания плагина hello-plugin1.jar

Структура проекта hello-plugin1 представлена на следующем скриншоте.

Класс HelloPlugin, расположенный в пакете «ru.plugins», реализует свойства интерфейса Plugin. При инициализации класса в методе init определяется значение контекста PluginContext родительского/вызвавшего объекта. Метод invoke выводит в консоль сообщение и изменяет надпись на кнопке родительского объекта.

package ru.plugins; import ru.plugin.Plugin; import ru.plugin.PluginContext; public class HelloPlugin implements Plugin < private PluginContext pc; @Override public void invoke() < System.out.println("Hello world. I am a plugin 1"); pc.getButton().setText("Other text 1"); >@Override public void init(PluginContext context) < this.pc = context; >>

Листинг pom.xml

Проектный pom.xml модуля hello-plugin1.jar включает GAV-параметры, секцию описания родительского GAV (), секцию зависимостей () и секцию сборки . В секции зависимостей указываются параметры модуля plugin-api. В описании секции сборки используется 2 плагина (maven-resources-plugin, maven-jar-plugin). Первый плагин включает в сборку ресурсы (resources/settings.properties), второй плагин создает jar и размещяет его в выходной директории () «$/../plugins».

 4.0.0 ru.plugins hello1 jar 1.0.0 Plugin Hello1 ru.pluggable.main pluggable 1.0.0   ru.pluggable plugin-api 1.0.0   $   maven-resources-plugin 2.6  copy-resources  $/target/resources  src/main/resources   **/*.properties        org.apache.maven.plugins maven-jar-plugin 2.3.1  $/../plugins

Примечание : второй плагин hello-plugin2 структурно ничем не отличается от hello-plugin1. Отличия касаются текста сообщения в консоли, надписи на кнопке и параметров GAV в pom.xml.

Проектный pom.xml модуля plugin-loader

Проектный pom.xml включает GAV-параметры jar-модуля, секцию описания родительского GAV (), секцию зависимостей () и секцию сборки . В секции зависимостей указываются параметры модуля plugin-api. В описании секции сборки используется плагин maven-jar-plugin, который создает jar и размещяет его в корневой директории проекта ().

 4.0.0 ru.pluggable.loader plugin-loader jar 1.0.0 Plugin Loader ru.pluggable.main pluggable 1.0.0   ru.pluggable plugin-api 1.0.0   $  org.apache.maven.plugins maven-jar-plugin 2.3.1  $/..   ru.pluggable.loader.Boostrap

Сборка проекта

Сборка всех проектов выполняется одной командой «mvn package» для корневого pom.xml. Maven сначала просматривает проектные файлы pom.xml всех модулей, определенных в корневом pom.xml, и после этого определяет порядок сборки модулей. Как следует из представленных ниже сообщений, выводимых Maven в консоль, порядок сборки был изменен и первым собирается модуль Plugin API, после чего формируются зависимые от него Plugin Loader, Plugin Hello1, Plugin Hello2.

D:\pluggable>mvn package [INFO] Scanning for projects. [INFO] ---------------------------------------------------- [INFO] Reactor Build Order: [INFO] [INFO] MultiModule application [INFO] Plugin API [INFO] Plugin Loader [INFO] Plugin Hello1 [INFO] Plugin Hello2 [INFO] [INFO] ---------------------------------------------------- [INFO] Building MultiModule application 1.0.0 [INFO] ---------------------------------------------------- [INFO] [INFO] ---------------------------------------------------- [INFO] Building Plugin API 1.0.0 [INFO] [INFO] --- maven-resources-plugin:2.6:resources \ (default-resources) @ plugin-api --- [INFO] Using 'UTF-8' encoding to copy filtered \ resources. [INFO] skip non existing resourceDirectory \ D:\pluggable\plugin\src\main\resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile \ (default-compile) @ plugin-api --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 2 source files to \ D:\pluggable\plugin\target\classes [INFO] [INFO] --- maven-resources-plugin:2.6:testResources \ (default-testResources) @ plugin-api --- [INFO] Not copying test resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile \ (default-testCompile) @ plugin-api --- [INFO] Not compiling test sources [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test \ (default-test) @ plugin-api --- [INFO] Tests are skipped. [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) \ @ plugin-api --- [INFO] Building jar: \ D:\pluggable\plugin\..\commons\plugin-api.jar [INFO] [INFO] ---------------------------------------------------- [INFO] Building Plugin Loader 1.0.0 [INFO] ---------------------------------------------------- [INFO] . . . [INFO] [INFO] ---------------------------------------------------- [INFO] Building Plugin Hello1 1.0.0 [INFO] ---------------------------------------------------- [INFO] . . . [INFO] [INFO] ---------------------------------------------------- [INFO] Building Plugin Hello2 1.0.0 [INFO] ---------------------------------------------------- . . . [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) \ @ hello2 --- [INFO] Building jar: \ D:\pluggable\hello-plugin2\..\plugins\hello2.jar [INFO] ---------------------------------------------------- [INFO] Reactor Summary: [INFO] [INFO] MultiModule application . SUCCESS [ 0.006 s] [INFO] Plugin API . SUCCESS [ 1.957 s] [INFO] Plugin Loader . SUCCESS [ 0.391 s] [INFO] Plugin Hello1 . SUCCESS [ 0.183 s] [INFO] Plugin Hello2 . SUCCESS [ 0.115 s] [INFO] ---------------------------------------------------- [INFO] BUILD SUCCESS [INFO] ---------------------------------------------------- [INFO] Total time: 2.802 s [INFO] Finished at: 2019-06-05T11:07:45+03:00 [INFO] Final Memory: 18M/199M [INFO] ----------------------------------------------------

Примечание :
1. При первой сборке проекта maven не нашел в репозитории модуль plugin-api.jar, прекратил сборку и вывел соответствующее сообщение. После размещения модуля plugin-api.jar в локальном репозитории командой «mvn install» сборка всего проекта прошла успешно.
2. После первой сборки проекта из локального репозитория был удален модуль plugin-api.jar. При дальнейших запусках сборки проекта Maven больше не ругался и сборка проходила нормально. Каким образом Maven собирает проект при отсутствии в локальном репозитории зависимого plugin-api.jar для меня осталось загадкой.

Скачать проект

Вы можете скачать рассмотренный пример по ссылке maven-mulimodule.zip (54.6 Кб)

Как собирать отдельные модули в многомодульном maven-проекте?

Подскажите пожалуйста, как лучше организовать многомодульный проект с возможностью сборки независимых модулей.
Возможно я некорректно изначально спланировал структуру такого проекта.. Это вполне возможно, т.к. я новичок и в maven, и вообще в разработке на Java.

Сейчас предполагается такая структура:

- general [parent] - src -main -java - JSON_Builder (класс для специфической компоновки JSON) - JSON_Parser (тоже что-то специфическое) - module_1 - src -main -java - некий класс, использующий JSON_Builder - module_2 - src -main -java - некий класс, использующий JSON_Parser

Стоит задача: в любой момент времени собрать функционал какого-то модуля (на жизненный цикл версий general-модуля можно не закладываться).
Целесообразно ли копировать зависимые классы в target/dependencies собираемого модуля в момент сборки?
Если есть под рукой ссылки на практики создания сложных проектов по зависимостям, буду очень признателен.

Вопрос задан более трёх лет назад
6429 просмотров

Комментировать
Решения вопроса 1

EugeneP2

Как то еще не встречал, чтоб в паренте объявлялись какие то классы. Он предназначен для объединения модулей и определения общих настроек и зависимостей;
Если вам нужен какой то общий для всех модуль, то создайте что то типа «core-module» и подключите его как зависимость к остальным модулям;
Что бы модули друг друга видели для зависимости, сделайте в корне парента: mvn install;

вот можете посмотреть на пример многомодульного проекта

Ответ написан более трёх лет назад
Денис @DZD Автор вопроса
Спасибо огромное!! Работает!
Только необходимо добавить дополнительное свойство:

 Main Class Name

в pom собираемого модуля. Иначе jar не запускается. Я собираю jar shade плагином.
Ответы на вопрос 1

Создаешь pom.xml, которая будет у тебя главной, и она будет хранить ссылки на помки, которые у тебя будут в каждом модуле хранится, вот так:

 child1 child2

Затем создаешь для каждого модуля pom.xml, которая будет ссылаться на своего родителя:

 groupIdParent artifactIdParent 1.0

Ответ написан более трёх лет назад
Денис @DZD Автор вопроса

Да. Пробовал.
Только вот классы, объявленные у родителя, не получается импортировать в код модуля. Пробовал добавить в dependency модуля ссылку на artifactId родителя. Не сработало, т.к. ожидается jar-файл, в котором maven ищет импортируемые классы.

А если это добавить после перента? jar Денис @DZD Автор вопроса

но ведь это же влияет на сборку конкретного потомка родительского проекта. У родителя стоит pom.
И я попробовал, как Вы предложили, не сработало.

Ваш ответ на вопрос

Войдите, чтобы написать ответ

maven

Maven
+1 ещё

Почему не запускается конфигурация для сервера wildfly?

1 подписчик
18 окт.
16 просмотров

Как создать многомодульный проект maven

многомодульный Maven проект

Многомодульный проект с Maven

2. Многомодульный проект Maven​

3. Преимущества использования мультимодулей​

4. Родительский POM​

5. Подмодули​

6. Создание приложения​

6.1. Создание родительского POM​

6.2. Создание подмодулей​

6.3. Создание проекта​

6.3. Включить управление зависимостями в родительском проекте​

6.4. Обновление подмодулей и сборка проекта​

7. Заключение​

Многомодульный maven проект

Описание многомодульного проекта

Листинг многомодульного корневого pom.xml

Модуль описания интерфейсов плагинов plugin-api.jar

Листинг pom.xml

Модуль описания плагина hello-plugin1.jar

Листинг pom.xml

Проектный pom.xml модуля plugin-loader

Сборка проекта

Скачать проект

Как собирать отдельные модули в многомодульном maven-проекте?

Войдите, чтобы написать ответ

Почему не запускается конфигурация для сервера wildfly?

Добавить комментарий Отменить ответ

2. Многомодульный проект Maven

3. Преимущества использования мультимодулей

4. Родительский POM

5. Подмодули

6. Создание приложения

6.1. Создание родительского POM

6.2. Создание подмодулей

6.3. Создание проекта

6.3. Включить управление зависимостями в родительском проекте

6.4. Обновление подмодулей и сборка проекта

7. Заключение