Как разделить фрагменты POM между различными POM - PullRequest
8 голосов
/ 11 января 2011

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

Я бы хотел сделать это чистым. На самом деле, я хотел бы определить общую конфигурацию «runnable-jar» и активировать ее в некоторых модулях.

Вот фрагмент POM, которым я хотел бы поделиться между несколькими проектами:

<build>
    <plugins>
       <plugin>

        <artifactId>maven-assembly-plugin</artifactId>
        <configuration>

            <!-- Use a custom descriptor, with suffix "bin" -->
            <descriptors>
                <descriptor>src/main/assembly/runnable-jar-assembly.xml</descriptor>
            </descriptors>

            <!-- Add main class to manifest -->
            <archive>
                <manifest>
                    <mainClass>${mainClass}</mainClass>
                </manifest>
            </archive>

        </configuration>

        <!-- Add build of this package to lifecycle -->
        <executions>
            <execution>
                <id>make-runnable-jar</id>
                <phase>package</phase>
                <goals>
                    <goal>single</goal>
                </goals>
            </execution>
        </executions>

       </plugin>
    </plugins>
</build>

В некоторых из POMS я хотел бы иметь возможность сделать что-то вроде:

<!-- Set the main class -->
<properties>
    <mainClass>my.main.Class</mainClass>
</properties>

<!-- Activate runnable jar build -->
<import>src/main/pom/runnable-jar-pom.xml</import> 

Я искал средство для импорта некоторых фрагментов XML в POM или для определения целого макроса набора узлов XML.

Для того, что я обнаружил, самым близким решением было бы определить профиль в родительском POM и активировать его в некоторых подмодулях, проверяя наличие файла. См. Этот связанный вопрос . Но я сталкиваюсь с проблемой некорректного наследования / установки свойства {basedir}.

Я нахожу очень удивительным, что нужен взлом, чтобы сделать что-то настолько простое (= обычно). Как вы обычно справляетесь с этим в Maven?

Ответы [ 4 ]

6 голосов
/ 12 января 2011

Я только что обнаружил что-то, что может решить мою проблему:

Модуль не обязательно должен быть субмодулем своего родительского модуля.

Родительский и субмодуль отношения являются отдельными понятиями.

Вы можете указать родительский модуль POM, который не является фактической родительской папкой в ​​структуре папок, с помощью атрибута lativePath (, как описано в документе )

В моем случае я использую следующую раскладку:

  • главный-проект
    • утилит (родитель: основной проект )
    • cli-программы (родитель: основной проект )
      • generic-cli (родитель: cli-Programs ; Пустой и пустой модуль POM)
      • cli-1 (родитель: generic-cli )
      • cli-2 (родитель: generic-cli )

Затем в generic-cli/pom.xml я могу объявить конфигурацию, которая является общей для всех моих программ cli (таких как пользовательские тестовые наборы, упаковка runnable-jar и т. Д.).

5 голосов
/ 12 января 2011

Один из способов сделать это - объявить ваш код <plugin> внутри <pluginManagement> родительского pom вашего многомодульного проекта.Отдельные модули могут иметь раздел <plugin>, который может использовать это без повторного выделения содержимого.

Родительский пом:

<pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-assembly-plugin</artifactId>
              ... all the details...
         </plugin>
         ...
     </plugins>
</pluginManagement>

Детский помп:

     <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
        </plugin>
     </plugin>
0 голосов
/ 11 марта 2016

Maven-плитки решает эту проблему.Это также в планах для Maven 3.x, отслеживается здесь .

0 голосов
/ 11 января 2011

не полный ответ, а решение основанной на них проблемы - использование общей схемы модулей, например root / modules / moduleA root / modules / moduleB.

Вы больше не можете создавать модули из своего собственного каталога, только через родительский проект. Но вы можете работать с профилями.

...