Maven — включить разные файлы во время сборки

Если вы хотите, чтобы каждый из проектов был отдельным, вы можете дать каждому проекту свой собственный файл pom.xml. В каждом дочернем проекте pom добавьте зависимость для родительского проекта. Это заставит сборку выполнить «наложение», в котором файлы из дочернего проекта будут добавлены (или перезаписаны файлы в) родительском проекте. Пример зависимости для дочернего проекта:

<dependency>
   <groupId>com.example.app</groupId>
   <artifactId>example</artifactId>
   <version>1.0.0</version>
   <type>war</type>
</dependency>

Я могу думать о решениях, основанных на профилях, плагине maven war и фильтрации, как описано в Добавление и фильтрация внешних веб-ресурсов.

Но это не отвечает на часть вашего вопроса как использовать веб-ресурсы в качестве "зависимостей".

Для этого Как для совместного использования ресурсов между проектами в Maven сообщение в блоге описывает что-то очень похожее и может помочь.

Профили должны хорошо подходить для этого. Согласно информации в документы профиля сборки maven, это не должно работать. В частности, говорят

build as specified inside of a profile is not a full implementation of the traditional
build POM element. This build is really another class in the model - from which the POM
build is derived - and only allows the plugins and pluginManagement subelements when 
defined here. This sidesteps any issues with secondary validation after the pom.xml is 
parsed in this case.

Но я только что протестировал его, и он включил соответствующие ресурсы, включив элемент сборки с определением ресурсов внутри.

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

<profile>
    <id>abc</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <resources>
            <resource>
                <directory>abc</directory>
                <includes>
                    <include>**/*</include>
                </includes>
            </resource>
        </resources>
    </build>
</profile>
<profile>
    <id>xyz</id>
    <activation>
        <activeByDefault>false</activeByDefault>
    </activation>
    <build>
        <resources>
            <resource>
                <directory>xyz</directory>
                <includes>
                    <include>**/*</include>
                </includes>
            </resource>
        </resources>
    </build>
</profile>

Затем у меня был каталог abc, содержащий файл abc.properties, и еще один xyz с соответствующим файлом xyz.properties.

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

Наконец, при сборке вы должны указать профиль веб-приложения, которое хотите создать, например, mvn -P abc clean install

Одна БОЛЬШАЯ проблема, которая может возникнуть при таком подходе, заключается в том, что каждый созданный артефакт будет иметь одно и то же имя, и один из них перезапишет другой в вашем локальном репозитории.

Да, я отвечаю на этот вопрос дважды, потому что каждый подход существенно отличается.

Вместо того, чтобы иметь один pom.xml с профилем для каждого из ваших файлов войны, вы можете иметь проект, содержащий 11 модулей. Один модуль maven со всем общим исходным кодом, а затем каждый из ваших военных файлов будет другим смежным модулем, в котором есть только файлы, специфичные для него. Все эти модули будут находиться под одним корневым pom.

В pom для каждого из ваших военных модулей вы должны настроить ресурсы и sourceDirectory в вашей конфигурации сборки, чтобы они указывали на ../base-project/src/main/resources и ../base-project/src/main/java соответственно.

Затем конфигурация maven-war-plugin будет иметь настройку webResources, указывающую на ../base-project/src/main/webapp И на ваши ресурсы войны в ./src/main/webapp.

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

Вы всегда можете использовать плагин maven-remote-resources. Вы должны создать сборки подмодулей для каждого из ваших наборов ресурсов, скажем, создать один с именем «my-project-resources-customer1.jar». Они похожи на любой другой артефакт maven и могут быть помещены в ваши локальные или удаленные репозитории.

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

<plugin>
    <artifactId>maven-remote-resources-plugin</artifactId>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>process</goal>
        </goals>
        <configuration>
          <resourceBundles>
            <resourceBundle>org.mygroup:my-project-resources-${profilename}:${pom.version}</resourceBundle>
          </resourceBundles>
        </configuration>
      </execution>
    </executions>
  </plugin>

Одно предостережение (его небольшое) заключается в том, чтобы быть осторожным при указании версий ресурсов, если вы используете плагин выпуска maven. Если ваши ресурсы и военный файл имеют общую версию, вы можете использовать свойство ${pom.version} в плагине. Затем, когда плагин выпуска обновит вашу родительскую версию до 1.1, плагин автоматически отразит это, используя версию 1.1 пакета ресурсов. Если вы не выпускаете пакеты ресурсов в ногу с войной, вы можете явно указать версию.

HTH

Ste