Совместное использование общих ресурсов между проектами maven, не относящимися к JAR

Я использовал плагин maven-remote-resources для аналогичного цель. Создайте отдельный проект ресурсов (com.company:resourceProj) типа jar. Поместите файлы ресурсов JMeter в /src/main/resources.

/src/main/resources/common.properties  (your filenames obviously)
/src/main/resources/a.properties
etc.

Следуйте инструкциям в примере, чтобы создать бандл.

Теперь добавьте эту конфигурацию в родительский POM (в профиль тестирования, если хотите):

<properties>
  <shared.resources.dir>${project.build.directory}/shared-resources</shared.resources.dir>
</properties>

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-remote-resources-plugin</artifactId>
  <executions>
    <execution>
      <id>load-resources</id>
      <phase>initialize</phase>
      <goals>
        <goal>process</goal>
      </goals>
      <configuration>
        <resourceBundles>
          <resourceBundle>com.company:resourceProj:version</resourceBundle>
        </resourceBundles>
        <attached>false</attached>
        <outputDirectory>${shared.resources.dir}</outputDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>

Теперь скажите Maven, что это тестовые ресурсы. Если элементы ваших тестовых ресурсов согласованы между модулями, это также может происходить в родительском элементе, если они разные, то в POM модуля. (По моему опыту с Maven 3 ресурсы, определенные в дочернем проекте, имеют приоритет над родительскими; они не объединяются.)

<testResources>
    <testResource>
      <directory>${shared.resources.dir}</directory>
      <includes>
         <include>common.properties</include>
         <include>${module.file}.properties</include>
      </includes>
    </testResource>
    <!-- any other test resources here -->
  </testResources>

В дочернем модуле определите свойство модуля ресурсов (это модуль a):

<properties>
  <module.file>a</module.file>
</properties>

Адаптируйте это под свой вариант использования.

---- Редактировать ----

Если конфигурация помещается в родительский POM, родительский POM может не построить в зависимости от того, какая конфигурация предоставляется дочерним. Когда мы создаем общие базовые / родительские проекты, мы не хотим требовать, чтобы были определены все свойства, которые должны предоставляться дочерними проектами (наследниками). Поэтому мы активируем этот профиль при создании общих проектов, чтобы обойти все, что относится только к детям.

Для этого добавьте пустой файл pom-packaging.marker в файл basedir родительского проекта. Затем добавьте этот профиль в родительский POM. Когда родительский проект построен, Maven найдет файл маркера, включит профиль и отключит все исполнения, включенные в профиль. Когда создается дочерний проект, файл маркеров не существует, поэтому настройки в основной части POM вступят в силу.

Я использовал эту технику и с плагином Enforcer - родительский элемент определяет правила enforcer, которые должны применяться к проектам, унаследованным от родительского, но не может удовлетворить правила при его сборке. Если плагин предоставляет свойство «пропустить», вы можете включить его в этом профиле вместо использования phase = none в конфигурации плагина.

<profile>
    <id>pom-packaging</id>
    <activation>
        <file>
            <exists>pom-packaging.marker</exists>
        </file>
    </activation>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-remote-resources-plugin</artifactId>
                <executions>
                    <execution>
                            <id>load-resources</id>
                            <phase>none</phase>    <!-- disables this execution -->
                        </execution>
                    </executions>
                </plugin>
          ....  other plugin executions here ....
         </plugins>
    </build>
</profile>

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

Вы создаете новый проект с упаковкой pom (может быть, на том же уровне, что и родительский?), А затем включаете его в родительский раздел dependencyManagement с областью действия import. Затем каждый из ваших дочерних проектов может получить его по наследству. Может показаться излишним делать весь проект для одного файла, но у меня не было бы с этим проблем.

Я на самом деле не пробовал это с деревом проектов, упакованных pom, так что вам, возможно, придется немного поиграться, но подход, который я считаю правильным. Здесь есть (очень обширный) пример:

Импорт зависимостей