Сборка произвольных файлов в многомодульном проекте Maven

Я пытаюсь создать сборку для большого (более 100 модулей) многомодульного проекта Maven.

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

Вот макет типичного модуля:

+- pom.xml
+- src
|  +- main
|     +- java
|        +- ...
|     +- resources
|        +- ...
|     +- scripts
|        +- ...

Этот модуль имеет упаковку JAR, поэтому основным артефактом является файл JAR.

Вот желаемый формат финальной сборки:

+- bin
|  +- <union of all files from src/main/scripts in the various modules>
+- lib
|  +- <union of all JAR files produced by the various modules>

Я знаю, как выполнить часть lib структуры сборки, но понятия не имею, как выполнить часть bin.

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

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

Прежде чем ответить, обратите внимание на следующие факты:

  1. В этом проекте используется плоская модульная структура (если это имеет значение). Переход на вложенную структуру невозможен.
  2. Не могу объединить скрипты в один модуль. Даже если бы я мог, есть другие произвольные файлы, которые также необходимо запаковать в финальную сборку, которые нельзя объединить в одном месте (я использовал скрипты в качестве простого примера для иллюстрации проблемы).
  3. Да, я думаю, что 100 модулей — это слишком много, но я не могу это контролировать.
  4. Учитывая большое количество модулей, я бы предпочел решение, которое не требует изменения каждого и каждого POM.

maven maven-assembly-plugin
person carej    schedule 27.08.2012    source источник
comment
Есть два варианта: maven-assembly-plugin и maven-shade-plugin   -  person yegor256    schedule 27.08.2012
comment
@ yegor256: да, я знаю об использовании плагина сборки; как я уже говорил в вопросе, я ищу альтернативу каждому модулю, объявляющему свою собственную сборку. Что касается тени, я не понимаю, как это поможет мне собирать произвольные файлы из других модулей. Можете ли вы уточнить?   -  person carej    schedule 28.08.2012

Ответы (2)


arrow_upward
0
arrow_downward

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

<files>
    <file>
      <source>../config-module/target/sample-config.xml</source>
      <outputDirectory>configs</outputDirectory>
    </file>
</files>

Путь ../config-module предполагает, что у вас есть модуль с таким именем. Я также предполагаю, что вы берете файл sample-config.xml из каталога target/, а не из каталога src/main/whatever.

Обратите внимание, что если ваши «произвольные файлы» являются артефактами Maven, сгенерированными каждым модулем (т.е. WAR), то может быть больше идоматических способов выполнить вышеуказанное. См.: Maven: The Complete Reference - "Best Practices "

person noahlz    schedule 27.08.2012
comment
есть ли способ сделать это, кроме относительных путей к каждому модулю? Я не хочу, чтобы модуль сборки (который у меня уже есть) был вынужден отслеживать, какие из более чем 100 модулей имеют произвольные файлы, а какие нет. Допускаются ли подстановочные знаки в элементе source? - person carej; 28.08.2012
comment
Да - прочтите раздел 8.6.2. Распределение (объединение) сборок в связанной книге. - person noahlz; 28.08.2012
comment
как я уже упоминал в OP, я хочу избежать сборки сборок. Вы хотите сказать, что нет другого хорошего способа сделать это, кроме сборки сборок? - person carej; 28.08.2012
comment
Согласно связанной книге Maven, сборка сборок - это путь. Лучше всего, чтобы каждый модуль генерировал один артефакт (т. е. JAR или WAR, но не WAR + сборку). Затем у вас есть модуль, называемый дистрибутивом, или что-то в этом роде, который представляет собой вашу сборку, которая извлекает содержимое из всех других модулей. - person noahlz; 28.08.2012
comment
спасибо за вклад. К сожалению, это, кажется, еще одна ситуация, когда путь Знатоков сталкивается с объективной реальностью: то, что я обнаруживаю, слишком знакомо в стране Знатоков. На данный момент я думаю, что мы напишем собственный плагин для удовлетворения наших требований. - person carej; 31.08.2012
comment
Просто интересно, что вы подразумеваете под объективной реальностью? Обратите внимание, что я понимаю, что вы подразумеваете под образом Maven. - person noahlz; 31.08.2012
comment
объективная реальность заключается в том, что у нас есть что-то, что не вписывается в обнесенный стеной сад Maven, и мы не хотим искажать наше исходное дерево во что-то, что более поддается Maven, поскольку это не имело бы смысла для того, как работают наши разработчики. - person carej; 31.08.2012

arrow_upward
0
arrow_downward

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

person carej    schedule 31.08.2012