Maven - создание дочерних проектов, которые могут быть независимыми от их родителей

Я немного из Maven newb, и я пытаюсь настроить проект maven, который создает несколько дочерних проектов, но все же позволяет кому-то просто захватить один из дочерних проектов и построить его независимо от родителя.

parentfolder
  ->pom.xml
  ->project1
    ->pom.xml
    ->src
  ->project2
    ->pom.xml
    ->src
  ->project3
    ->pom.xml
    ->src

В принципе, я хочу, чтобы кто-то мог проверить родительскую папку и выполнить компиляцию mvn для создания всех проектов, а также для того, чтобы кто-то мог проверить только проект1 и сделать mvn-компиляцию для его создания.

Я пробовал объявить подпроекты как модули в pom.xml верхнего уровня,

<modules>
  <module>project1</module>
  <module>project2</module>
  <module>project3</module>
</modules>

Но, похоже, требуется, чтобы родительская информация pom.xml была объявлена ​​в дочерних элементах. Это делает дочерние проекты зависимыми от родительского pom.xml, и это то, чего я хотел избежать.

Ответы

Ответ 1

Вы должны позаботиться о различиях между отношением родитель-ребенок и концепцией агрегации в Maven2. Это не тот же принцип, даже если они действительно часто используются в одно и то же время.

РОДИТЕЛИ

Первая концепция заключается в том, что проект объявляет в своем pom.xml родительский pom.xml:

<project>
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>foo</groupId>
        <artifactId>bar</artifactId>
        <version>42</version>
    </parent>
    ...

В этом случае для создания этого компонента родительский проект должен быть найден в локальном хранилище. Это ваш случай здесь.

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

Это точно такая же концепция extends в языке Java.

АГРЕГИРОВАНИЕ

В этом случае у вас есть проект, который объединяет несколько module указывая их имена в узлах module:

<modules>
    <module>commons</module>
    <module>client</module>
    <module>server</module>
    ...
</modules>

Это означает, что каждая команда, которую вы будете запускать в этом корневом проекте, будет выполняться на каждом модуле (порядок определяется реактором Maven 2). Например, если вы запустите mvn clean install в корневом проекте, Maven 2 выполнит эту команду в корневом проекте, затем в commons проектах, затем на client и, наконец, на server.

В этой концепции вы можете скомпилировать один проект без компиляции какого-либо другого проекта (кроме случаев, когда есть взаимозависимости, конечно).

Вот схема, которая показывает две разные концепции:

alt text

У вас есть более подробное объяснение этих двух понятий в Maven: Полное руководство, здесь.

Ответ 2

Подпроекты зависят только от родителя, если они используют <parent> tag (наследование maven). Вы не обязаны использовать <parent> тег в подмодулях. Однако, если вы хотите, чтобы ваши модули наследовали общие элементы родительского пом, вам нужно использовать наследование maven.

Строго говоря, если вы используете наследование и хотите построить только суб-проект, то родительский pom.xml не должен присутствовать в родительском каталоге; до тех пор, пока maven может найти родительский pom в локальном или удаленном репозитории, тогда он будет строить. На практике, если в вашем родительском помпе происходят изменения, вам нужно будет выяснить, как заставить членов вашей команды следить за родительским pom.

Ответ 3

Родительский pom и его версия должны быть объявлены в дочерних элементах.

Если ваши проекты объявлены родителями, они должны быть доступны либо в сборке, поэтому один из модулей должен быть родительским pom или в репозитории. Вы, кажется, говорите, что хотите, чтобы кто-то проверял проект, который зависит от родителя, но не имеет доступа к родительскому элементу и все еще может построить проект, который похож на попытку создания проекта без его зависимостей.

Вы можете настроить родительский pom:

  • Создайте общедоступный репозиторий maven, разверните родительский pom и разместите информацию о репозитории в дочерних poms.
  • Вы можете сказать maven, чтобы искать родительский pom на относительном пути, прежде чем он проверит репозитории (это поможет вам, когда у вас есть локальные изменения родительского помпы, еще не развернутые). Таким образом, вы можете с уверенностью сделать svn: внешний или его эквивалент в своем дочернем проекте вашему родительскому pom.

Ответ 4

Мне кажется, что проблема в том, что Maven перегружает родительский тег. Maven docs продолжают говорить мне, что Inheritance and Aggregation - это две разные вещи, но оба используют один и тот же тег для достижения своей функции. Это противоречит сценарию, который задает оригинальный плакат. Можно захотеть

  • наследует определенные настройки из общего родителя, но
  • имеют две сборки разных приложений, совместно использующих общий компонент.

Таким образом, мы имеем два разных понимания родительского отношения. Во-первых, "родитель" вносит настройки для каждого модуля, а во-вторых, "родительский", чья сборка создает дочерний элемент. Поскольку есть два последних, это ломается. Две идеи о происхождении происходят друг с другом.