5 лучших захватывающих идей и тем для многомодульных проектов Maven для начинающих [2022]

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

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

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

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

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

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

Читайте также: Ответ на вопрос на интервью с Maven

Ключевые термины, которые нужно знать о многомодульных проектах в Maven

1. Родительский POM (модуль объекта проекта)

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

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

2. Подмодули

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

3. Простой многомодульный проект

App и util — это два модуля, которые содержатся в The Simple Multi-Module Project. Модуль util необходим для предоставления статического метода для объединения или добавления различных строк с использованием библиотеки Apache Commons Lang, а модуль приложения необходим для вызова модуля util. Вот фрагмент из файла app.java:

простой-мульти/приложение/src/main/java/приложение/App.java

приложение общественного класса {

public static void main(String[] args) {

System.out.println(new App().greet("Мир!"));

}

общедоступное приветствие строки (имя строки) {

return Util.join («Привет», имя);

}

}

Чтобы собрать проект, запустите

$ cd простой мульти

$ mvn чистый тест

Компоновщик кода Maven строит оба модуля вашего проекта в правильном порядке, выполняет необходимые тесты и выводит результаты в понятном сводном формате, как показано ниже:

4. Структура многомодульного проекта

Вот схема простого многомодульного проекта:

Каталог simple-multi является корневым каталогом и находится в самом начале всего проекта. Он содержит POM верхнего уровня (родительский POM), но этот родительский POM не имеет исходной папки.

Каталог верхнего уровня также содержит app и util, которые представляют собой обычные проекты Maven с каталогами и файлом pom.xml.

POM верхнего уровня и POM модуля немного отличаются от обычного POM. Рассмотрим подробно, что они содержат:

5. ПОМ верхнего уровня

Родительский POM или POM верхнего уровня требуется многомодульному проекту Maven в корневом каталоге.

POM верхнего уровня определяет важные аспекты и координаты проекта, такие как идентификатор артефакта, версия и идентификатор группы, как и в любом обычном проекте. Однако тип упаковки для этого не в обычном формате войны или банки, а в виде помпона. Это связано с тем, что модуль верхнего уровня не содержит никакого дополнительного исходного каталога. Элементы modules/module добавляют модули app и util.

Содержимое этого файла включает:

простой-мульти/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<groupId>org.codetab</groupId>

<artifactId>простой мульти</artifactId>

<версия>1.0</версия>

<packaging>бумага</packaging>

<модули>

<module>приложение</module>

<module>использовать</module>

</модули>

</проект>

Подводя итог, POM верхнего уровня указывает тип упаковки pom и явно перечисляет все подмодули.

Имейте в виду, что вам не нужно беспокоиться о порядке при объявлении подмодулей в родительском POM, поскольку Maven использует Reactor для правильного упорядочения перечисленных модулей. В простом множестве maven создает модуль util, а затем приложение, поскольку приложение зависит от util.

5. Модуль ПОМ

Папка Module POM содержит обычную исходную папку и собственный файл pom.xml. Содержимое этого файла util/pom.xml:

утилита/pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<modelVersion>4.0.0</modelVersion>

<родительский>

<groupId>org.codetab</groupId>

<artifactId>простой мульти</artifactId>

<версия>1.0</версия>

</родительский>

<artifactId>использовать</artifactId>

<свойства>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

<maven.compiler.source>1.8</maven.compiler.source>

<maven.compiler.target>1.8</maven.compiler.target>

</свойства>

<зависимости>

<зависимость>

<groupId>org.apache.commons</groupId>

<artifactId>commons-lang3</artifactId>

<версия>3.6</версия>

</зависимость>

<зависимость>

<groupId>подразделение</groupId>

<artifactId>юнит</artifactId>

<версия>4.12</версия>

<scope>тест</scope>

</зависимость>

</зависимости>

</проект>

Нет необходимости указывать идентификатор группы и версию для модуля, так как они будут унаследованы от родителя. Блок зависимостей/зависимостей определяет зависимости служебного модуля — commons-lang3 и JUnit.

Теперь давайте посмотрим на app/pom.xml, который очень похож на util/pom.xml, за исключением блока зависимостей, показанного ниже:

приложение /pom.xml

….

<зависимости>

<зависимость>

<groupId>org.codetab</groupId>

<artifactId>использовать</artifactId>

<версия>1.0</версия>

</зависимость>

….

</зависимости>

Модуль приложения использует методы из модуля util, и для этого app/pom.xml указывает util в качестве зависимости.

Подводя итог всему вышеописанному:

Проект верхнего уровня (родительский проект),

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

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

• Родительский элемент указывает родителя модуля.
• Координаты модуля задаются в элементе ArtifactID. GroupID и версия не упоминаются, так как они наследуются от родительских координат.
• Зависимость, если один модуль зависит от другого, упоминается в элементе dependencies/dependency.

Выполнение многомодульного проекта

Команду $ mvn clean package можно использовать для компиляции, тестирования и упаковки мультимодуля. Однако для его запуска с помощью maven-exec-plugin необходимо выполнить следующие шаги:

Выполните следующие команды:

$ cd простой мульти

$ mvn чистая установка

$ mvn exec:java -pl приложение -Dexec.mainClass=app.App

Команда install устанавливает модули в ваш локальный репозиторий, где вы затем можете запустить проект. Опция -pl app информирует подключаемый модуль exec о модуле приложения и запускает его класс app.App. Без установки процесс сборки завершится ошибкой, так как Maven не сможет загрузить и разрешить зависимость модуля util.

Однако довольно обременительно каждый раз перед каждым запуском устанавливать проект в локальный репозиторий, особенно на этапе разработки. Чтобы облегчить это, вы можете напрямую запустить мультимодуль в Eclipse IDE, не выполняя шаг установки.

Изучайте онлайн -курсы по разработке программного обеспечения в лучших университетах мира. Участвуйте в программах Executive PG, Advanced Certificate Programs или Master Programs, чтобы ускорить свою карьеру.

Заключение

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

Если вам интересно узнать больше о разработке программного обеспечения с полным стеком, ознакомьтесь с программой Executive PG upGrad и IIIT-B по разработке программного обеспечения — специализация в разработке полного стека, которая предназначена для работающих профессионалов и предлагает более 500 часов тщательного обучения, 9 + проекты и задания, статус выпускника IIIT-B, практические практические проекты и помощь в трудоустройстве в ведущих фирмах.