В образовательных целях я настроил расположение проекта как так (плоский, чтобы к комплекту затмевают лучше):
-product
|
|-parent
|-core
|-opt
|-all
Родитель содержит совокупный проект с ядром, выбрать и так далее. Ядро реализует обязательную часть приложения. Выберите дополнительная часть. Все, как предполагается, объединяется, ядро с выбирают, и перечислили эти два модуля как зависимости.
Я теперь пытаюсь сделать следующие артефакты:
Большинство из них довольно просто для создания. У меня действительно есть некоторая проблема с агрегирующимися артефактами все же. Мне удалось сделать product-all-src.jar с пользовательским дескриптором блока во 'всем' модуле, который загружает источники для всего непереходного deps, и это хорошо работает. Эта техника также позволяет мне делать product-all-with-dependencies.jar.
Я однако недавно узнал, что можно использовать source:aggregate цель в исходном плагине к совокупным источникам всего совокупного проекта. Это также верно для javadoc плагина, который также агрегируется посредством использования родительского проекта.
Таким образом, я порван между моим 'всем' подходом модуля и отказом от 'всего' модуля и просто использую 'родительский' модуль для всего агрегирования. Это чувствует себя грязным, чтобы иметь некоторые совокупные артефакты, произведенные в 'родителе' и других, произведенных 'всего'. Существует ли способ сделать 'продукт - вся' банка в родительском проекте или агрегировать javadoc во 'всем' проекте? Или я должен просто сохранить обоих?
Спасибо
Сплющенные деревья больше не используются. Это было сделано несколько лет назад, чтобы разобраться с тем, как Eclipse обрабатывает проекты, и с отсутствием хорошей интеграции Maven и Eclipse. Если вы используете m2eclipse для импорта проектов Maven в Eclipse, у вас не будет проблем с вложенным деревом, типичным для maven.
Каков хороший пример того, как структурировать сборку Maven? Исходный код проекта Maven сам . В нем есть все, что вам нужно, включая последнюю сборку , которая упаковывает пакеты.
Типичная вложенная структура имеет иерархию сверху вниз, где родительский элемент выполняет агрегирование модулей ниже него, а дочерние элементы наследуют значения от родителя. Хотя они могут и иногда являются отдельными, это не норма.
Я бы предложил просто сохранить дескриптор сборки из «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). Возможно, это будет больше подспорьем.