Maven: локальная разработка развертывание против объединения для распространения

Question

Терпите меня, я перехожу из Ant в Maven2: мне кажется, я столкнулся с одной из тех мелочей, которые были просты в Ant, но не так в Maven ...

Как справиться с разницей между локальным развертыванием и созданием архива / пакета для распространения на другую машину?

Давайте предположим, что вывод моего проекта - EAR плюс некоторые дополнительные конфигурационные файлы. разработчик , который активно работает над проектом, должен будет часто развертывать и повторно развертывать на своем локальном сервере приложений (скажем, JBoss), а Integration Engineer , который разрабатывает для QA / production понадобится только для создания окончательной архивной сборки (tar / gz).

В Ant у нас было две цели для этого: «dev-deploy» и «bundle». Оба выполняют полную сборку, но отличаются на последнем шаге: «dev-deploy» копирует файлы EAR и конфигурации в соответствующие локальные папки, тогда как «bundle» просто помещает файлы EAR & config в сборку tar.gz.

Как вы делаете это в Maven?

Я видел, что плагин сборки может создавать либо архивы (tar, gz и т. Д.), Либо разнесенные каталоги (из одного и того же дескриптора сборки). Я могу вызвать либо сборка: сборка , либо сборка: каталог , но для последнего, как мне скопировать окончательный вывод в локальные папки развертывания JBoss? Из связанного поста кажется, что специальное копирование файлов не совсем то, чем занимается Maven, так что antrun-копия, вероятно, является наиболее подходящей?

Наконец, поскольку тип сборки может отличаться в зависимости от того, кто ее вызывает, не кажется разумным привязывать сборку к жизненному циклу сборки, не так ли? Но это означает, что разработчику всегда нужно будет вызывать 'mvn package' , а затем 'mvn assembly: directory' , чтобы пересобрать и протестировать изменение. И наоборот, Интеграционному инженеру всегда нужно будет запустить 'mvn package' , а затем 'mvn assembly: assembly' для создания распространяемого архива. Я надеялся на решение с одной командой для каждого, или я должен просто написать его?

Answer 1

В Ant у нас было две цели для этого: «dev-deploy» и «bundle». Оба выполняют полную сборку, но отличаются на последнем этапе: «dev-deploy» копирует файлы EAR и конфигурации в соответствующие локальные папки, тогда как «bundle» просто помещает файлы EAR & config в сборку tar.gz.

Не уверен, что вы подразумеваете под соответствующими локальными папками о "dev-deploy", но это похоже на то, что делает mvn pacakge, а "bundle" действительно звучит как maven сборка .

Я видел, что плагин сборки может создавать либо архивы (tar, gz и т. Д.), Либо разнесенные каталоги (из одного и того же дескриптора сборки). Я могу вызвать любой каталог: Assembly: Assembly или Assembly: но для последнего, как мне скопировать окончательный вывод в локальные папки развертывания JBoss? Из соответствующего поста кажется, что специальное копирование файлов не совсем то, чем занимается Maven, так что antrun-копия, вероятно, является наиболее подходящей?

Полагаю, здесь мы говорим о задачах Интегратора. Поскольку вы не объяснили, что именно содержит «пакет», каков целевой сервер приложений (насколько я понимаю, вы также используете JBoss для QA / production, но, опять же, это предположение), если этот пакет должен быть развертывается автоматически, трудно представить все решения и / или альтернативы antrun. Но на самом деле, для копирования / перемещения / распаковки / любой сборки, плагин maven antrun является кандидатом.

Наконец, поскольку тип сборки может различаться в зависимости от того, кто ее вызывает, не кажется разумным привязывать сборку к жизненному циклу сборки, не так ли? Но это означает, что разработчику всегда нужно будет вызывать «пакет mvn», а затем «mvn assembly: directory», чтобы пересобрать и протестировать изменение. И наоборот, Интеграционному Инженеру всегда нужно будет запустить mvn package, а затем mvn assembly: assembly, чтобы создать распространяемый архив. Я надеялся на решение для одной команды для каждого, или я должен просто написать его?

Насколько я понял, инженер по интеграции строил пакет. Зачем разработчику пакет? Это сбивает с толку ... Во всяком случае, мне не нужны детали, чтобы придумать ответ. На самом деле вы можете объявить подключаемый модуль сборки maven в определенные профили сборки , один для разработки и один для интеграции, и связать либо single, либо directory-single мохос к жизненному циклу сборки проекта в каждом профиле. Это позволило бы использовать только одну команду и избежать каких-либо сценариев (на самом деле, не делайте этого).