2013-09-06 4 views
3

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

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

+ generation 
    - mod1 
    - mod2 
    - mod3 

корень POM (поколение) генерирует Java исходный код (.java), основанный на модели UML, хранящейся в каталоге/УМЛ. Затем модули (mod1 ... 3) компилируют различные подмножества этого исходного кода и упаковывают вывод как банку.

Я хочу повторно использовать эту процедуру сборки и применить ее к различным моделям 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 

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

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

ответ

0

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

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

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

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

+0

Я там с вами. Прослеживаемость - очень важный момент. Поэтому различные модели UML также упаковываются в банки и версируются maven. В проекте генерации модуль добавляется как зависимость и распаковывается во время фазы генерации источников. Предпочтительно, я просто должен был бы указать другую зависимость модели. – beaker

0

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

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