Параметризация многомодульной сборки Maven

Я ищу возможность параметризовать многомодульную сборку таким образом, чтобы я мог заменить/указать некоторые файлы (например, файлы UML), которые используются во время сборки, для получения другого вывода. Процедура сборки остается прежней, но я хочу иметь возможность создавать разные выходные данные в зависимости от входной модели UML.

У меня есть многомодульный проект, который создает несколько банок на основе модели UML. Структура помпона выглядит следующим образом:

+ generation
  - mod1
  - mod2
  - mod3

Корневой pom (генерация) генерирует исходный код Java (.java) на основе модели UML, хранящейся в каталоге /uml. После этого модули (mod1...3) компилируют отдельные подмножества этого исходного кода и упаковывают вывод в виде jar.

Я хочу повторно использовать эту процедуру сборки и применить ее к различным моделям UML. Как я могу повторно использовать всю процедуру генерации, компиляции и упаковки, определенную в многомодульном проекте, в других проектах maven?

# Generate jars based upon the foo UML model
+ generation-foo
  /uml/foo.uml

# Generate jars based upon the bar UML model
+ generation-bar
  /uml/bar.uml

Обновить
Я мог бы использовать профили в проекте генерации, чтобы определить различные входные модели uml, а затем просто активировать соответствующую модель. Но таким образом я потерял бы прослеживаемость.

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


java maven inheritance multi-module
person beaker    schedule 06.09.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

При этом многое возможно с properties в POM, который затем можно передать в командной строке: -Dproperty=value. Похоже, вы сможете передать свойство любому процессу, генерирующему исходный код.

Однако я могу выразить некоторую осторожность. Я вижу некоторые возможные красные флажки в общем дизайне, который вы описываете. Если модули (независимо от их отношений наследования) проходят через файлы/папки, желательно, чтобы они проходили через installation. Так что, если вы это сделаете, вы получите версию родительского проекта в своем локальном репозитории, о которой вы на самом деле не знаете, что это такое. Какие параметры использовались? И как пользователь этого артефакта справится с этим?

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

person Sander Verhagen    schedule 06.09.2013
comment
Я рядом с тобой. Отслеживаемость — очень важный момент. Поэтому различные модели UML также упакованы в банки и управляются maven. В проекте генерации модуль добавляется как зависимость и распаковывается на этапе генерации источников. Предпочтительно, чтобы мне просто нужно было указать другую зависимость модели. - person beaker; 06.09.2013

arrow_upward
0
arrow_downward

Я не совсем уверен, что понимаю ваши варианты использования, но вы можете посмотреть на:

  • Наследование POM: максимально возможное определение в родительском модуле (разные группы модулей могут иметь один и тот же родительский элемент).
  • Профили Maven: вы можете активировать на основе всевозможных потенциальных соглашений, таких как даже название проекта.
  • Архетипы Maven: И, наконец, я думаю, основываясь на том, что вы говорите, это, возможно, единственное решение многократно используемого шаблона проекта.
person Adam Gent    schedule 06.09.2013