Maven - все или родительский проект для агрегации? - PullRequest
Новая
       20

Maven - все или родительский проект для агрегации?

5 голосов
/ 12 мая 2010

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

-product
 |
 |-parent
 |-core
 |-opt
 |-all

Родитель содержит агрегатный проект с core, opt и всем. Ядро реализует обязательную часть приложения. Опция является необязательной частью. Предполагается, что все объединит core с opt, и эти два модуля будут перечислены как зависимости.

Я сейчас пытаюсь сделать следующие артефакты:

  1. продукт-core.jar
  2. Продукт-ядро-src.jar
  3. продукт-ядро-с-dependencies.jar
  4. продукт-opt.jar
  5. продукт-неавтоматического src.jar
  6. продукт-неавтоматического с-dependencies.jar
  7. продукт-all.jar
  8. продукт-все-src.jar
  9. продукт-все-с-dependencies.jar

Большинство из них довольно просты в производстве. У меня есть некоторые проблемы с агрегирующими артефактами. Мне удалось создать product-all-src.jar с пользовательским дескриптором сборки в модуле «all», который загружает исходные коды для всех нетранзитивных deps, и это прекрасно работает. Этот метод также позволяет мне сделать product-all-with-dependencies.jar.

Однако недавно я обнаружил, что вы можете использовать цель source: aggregate в плагине source для агрегирования источников всего агрегатного проекта. Это также верно для плагина javadoc, который также агрегируется за счет использования родительского проекта.

Так что я разрываюсь между подходом «все» и отказом от модуля «все» и просто использую «родительский» модуль для всей агрегации. Кажется нечистым иметь некоторые совокупные артефакты, созданные в «родительском», а другие - во «всем». Есть ли способ сделать jar «product-all» в родительском проекте или объединить javadoc в «all» проекте? Или мне просто оставить оба?

Спасибо

Ответы [ 2 ]

5 голосов
/ 06 июня 2010

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

Что является хорошим примером того, как структурировать сборку Maven? Источник проекта Maven сам . В нем есть все нужные вам части, включая окончательную сборку , которая упаковывает пакеты.

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

0 голосов
/ 13 мая 2010

Я бы предложил просто оставить дескриптор сборки в «all», переместить его в parent / и соответствующим образом изменить parent / pom.xml, а затем создать эту сборку, выполнив что-то вроде mvn -f parent/pom.xml assembly:assembly. Другими словами, да, удалите избыточный проект для «всего», так как он просто дублирует то, что «родитель» уже делает.

Кстати, «родитель» кажется плохим выбором имен для этого проекта, если это агрегатный проект, а не просто родительский pom.xml.

[Изменить]

Хотя это гораздо более крупный проект, возможно, проект, который изложен в том виде, в каком вы его представляете, является проектом Apache Camel. Проверьте это здесь: http://camel.apache.org/source.html. Существует родительский модуль / модуль, который обрабатывает все для всего остального, и отдельный модуль для создания фактических дистрибутивов сборки в apache-camel / (с дескрипторами сборки в apache-camel / src // main / descriptors). Возможно, это больше поможет.

...