Как создать многомодульный проект 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, и вообще в разработке на 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 собираемого модуля в момент сборки?
Если есть под рукой ссылки на практики создания сложных проектов по зависимостям, буду очень признателен.

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

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

1. Как то еще не встречал, чтоб в паренте объявлялись какие то классы. Он предназначен для объединения модулей и определения общих настроек и зависимостей;
2. Если вам нужен какой то общий для всех модуль, то создайте что то типа «core-module» и подключите его как зависимость к остальным модулям;
3. Что бы модули друг друга видели для зависимости, сделайте в корне парента: 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.
И я попробовал, как Вы предложили, не сработало.

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

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

• Java
• +3 ещё

Проблема запуска автотестов с помощью Jenkins, в чем может быть ошибка?

• 1 подписчик
• 09 нояб. 2023
• 123 просмотра

Многомодульный проект с 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 можно воспользоваться плагином archetype. Последовательность действий следующая:
  1. В командной строке вызываем цель generate плагина archetype. mvn archetype:generate 2. В появившемся списке шаблонов создания проекта, нужно выбрать шаблон, создающий корневой многомодульный проект. Для этого в командной строке вводим имя нужного шаблона pom-root

  Choose a number or apply filter (format: [groupId:]artifactId, case sensitive co ntains): 221: pom-root

  После этого в списке останется только нужный нам шаблон, вводим его номер

  Choose archetype: 1: remote -> org.codehaus.mojo.archetypes:pom-root (Root project archetype for c reating multi module projects) Choose a number or apply filter (format: [groupId:]artifactId, case sensitive co ntains): : 1

  Выбираем версию шаблона, по-умолчанию берется самая последняя версия

  Choose org.codehaus.mojo.archetypes:pom-root version: 1: 1.0 2: 1.0.1 3: 1.1 Choose a number: 3:

  3. Далее как и при создании любого проекта maven вводим последовательно следующие координаты проекта: groupId, artifactId, version. После чего подтверждаем создание проекта.

  Define value for property 'groupId': : ru.javacore Define value for property 'artifactId': : mainProject Define value for property 'version': 1.0-SNAPSHOT: : 1.0 Define value for property 'package': ru.javacore: : ru.javacore Confirm properties configuration: groupId: ru.javacore artifactId: mainProject version: 1.0 package: ru.javacore Y: : Y

  После того как родительский проект создан, можно создавать подпроекты. Для этого переходим в папку созданного родительского проекта, и так же с помощью плагина archetype создаем простой jar-проект (шаблон maven-archetype-quickstart) или web-проект (шаблон maven-archetype-webapp) и т.д.

  Похожие публикации:

  1. Как включить designer в powerpoint
  2. Как включить подсказки в jupiter notebook
  3. Как выровнять формы в html
  4. Как написать дискорд бота на node js