В чем разница между использованием опции maven -pl и запуском maven с уровня модуля?

Question

Есть ли разница между

C:/dev/path/to/Project> mvn package -pl MyModule -am -s settings.xml 

и

C:/dev/path/to/Project/MyModule> mvn package -am -s ../settings.xml 

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

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

Answer 1

Давайте сначала проясним что-то о сборке с несколькими модулями (агрегатор) (то есть, вызывая сборку из агрегатора/родительского проекта) и построив один модуль.

Давайте будем использовать следующий пример:

-+ modules-project 
|- module-a 
|- module-b (depends on module-a) 

Поэтому модули-проект будет иметь в составе своей ПОМ следующее:

<modules> 
    <module>module-a</module> 
    <module>module-b</module> 
</modules> 

При сборке из папки модуля проекта:

module-project> mvn clean install 

Maven Reactor создаст граф зависимостей объявленного модуля s и строить их соответствующим образом, следовательно, модуль-а будет построен до модуля-б, поскольку модуль-Ь зависит от модуля-а

module-b> mvn clean install 

будет работать правильно, только строительный модуль-б, разрешающий модуль-а как зависимость (который мы установили ранее) и используя его как часть пути класса сборки, где это необходимо.

Если вместо того, чтобы вызывать в clean install на модули-проекта мы ссылались на clean package, Maven не был бы установлен либо в нашем локальном кэше Maven, следовательно, зависимость к модулю-а в проекте модуль-б не может быть решена , Для уточнения:

module-project> mvn clean package 

Будет ли еще построить весь проект (со всеми его подмодулями) и создать пакеты (то есть, файлы банка).

module-b> mvn clean package 

теперь будет неудачу, потому что зависимость к модулю-а не в локальном кэше Maven, ни в каком-нибудь хранилище Maven, то есть, она не существует как зависимость и Maven не знать что-либо о других модулях, он строит простой проект (модуль) без каких-либо знаний о других модулях (как это предусмотрено модулями-проектом). При создании модулей-проектов вместо этого Maven строит каждый модуль с гораздо большей информацией, зная, что модуль имеет зависимость от другого модуля, он не будет смотреть в локальном кеше или в любом репозитории Maven для зависимостей между модулями. Опять же, это reactor build.

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

• Построить весь проект из нескольких модулей (mvn clean install)
• Построить одинарный или набор модулей с помощью опции -pl (но начиная с проекта мульти-модуль)
• создать один или набор модулей и их зависимости через -pl и -am варианты (до сих пор от проекта мульти-модуля)

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

modules-project> mvn clean package -pl module-a 

Будет функционировать, только строящийся модуль, как часть сборки реактора. Однако

modules-project> mvn clean package -pl module-b 

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

модули-проект> МВН чистый пакет -pl модуль-б -am

в конечном итоге будет работать нормально, потому что теперь Maven также строит зависимые модули (благодаря -am) и точно знает, где их найти (как часть многомодульной информации, то есть раздел modules).

Давайте посмотрим на последний случай:

модуль-б> МВН чистый пакет -am

Would неудачу, если мы никогда не устанавливали весь проект из нескольких модулей (т.е. мы всегда запускать clean package), опция -am будет проигнорирована, если не будет частью сборки реактора (поскольку она является опцией reactor, а не нормальной сборки), и Maven все равно попытается найти модуль-a в локальном кеше или в репозиториях.

Именно поэтому вы всегда должны создать суб-модуль из агрегатора/родителя и через -pl и -am варианты, чтобы убедиться, что:

• Вы строите правильно, используя правильные зависимости и модули информационных
• вы строите против последней версии вашего кода/зависимость, а не против чего-то вы установили ранее в кэше Maven, которые не могут быть приведены в соответствие с кодом своего модуля

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

Дополнительную информацию об этих вариантах для сборки реактора можно найти here.