Знаток - 'весь' или 'родительский' проект для агрегирования?

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

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

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

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

  1. продукт-core.jar
  2. product-core-src.jar
  3. product-core-with-dependencies.jar
  4. продукт-opt.jar
  5. product-opt-src.jar
  6. product-opt-with-dependencies.jar
  7. продукт-all.jar
  8. product-all-src.jar
  9. product-all-with-dependencies.jar

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

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

Таким образом, я порван между моим 'всем' подходом модуля и отказом от 'всего' модуля и просто использую 'родительский' модуль для всего агрегирования. Это чувствует себя грязным, чтобы иметь некоторые совокупные артефакты, произведенные в 'родителе' и других, произведенных 'всего'. Существует ли способ сделать 'продукт - вся' банка в родительском проекте или агрегировать javadoc во 'всем' проекте? Или я должен просто сохранить обоих?

Спасибо

5
задан sal 17 May 2010 в 16:38
поделиться

2 ответа

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

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

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

5
ответ дан 14 December 2019 в 19:05
поделиться

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

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

[Edit]

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

0
ответ дан 14 December 2019 в 19:05
поделиться
Другие вопросы по тегам:

Похожие вопросы: