Sharing common resources between non-JAR maven pro

Question

I have several Maven projects, say a,b,c, inheriting from a single parent (let's call it parent), and also being modules (of a different project than parent, let's call it super).

These projects all have a pom packaging. Each of these projects has specific configuration, but they also have a common part. To be more speficic, each project two JMeter test configuration files: one specialized for the given project, and another one that is common and identical for all projects.

The problem is - how should I configure the POMs so this common config file is shared among the projects?

A workaround would be to merge all of them into super, and use profiles. However, in this case, I would have to do a separate build for each configuration manually (whereas now I can just build super).

There are similar questions, like this one, but they deal with the jar plugin, which is not relevant for this case.

Structure, for reference:

• POM Inheritance:

      parent
        |
  -------------
  |     |     |
  a     b     c
  

• File structure:

  super
  |
  |-a
  |
  |-b
  |
  |-c
  

Answer 1

The idea with import scope dependencies is that you can put shared resources into a separate project, which is then imported by a number of other ones; I was thinking you could include your shared config file in this way.

You create a new project with packaging pom (maybe at the same level as the parent?), and then include it in the parent's dependencyManagement section with scope import. Each of your child projects can then receive it by inheritance. It might seem like overkill to make an entire project for just a single file, but I wouldn't have a problem with that.

I haven't actually tried this with a tree of pom-packaged projects, so you might have to play around a bit, but the approach I think is sound. There's a (very extensive) example here:

Importing Dependencies

Answer 2

I have used the maven-remote-resources-plugin for a similar purpose. Create a separate resources project (com.company:resourceProj) of type jar. Put the JMeter resource files in /src/main/resources.

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

Follow the directions in the example to create the bundle.

Now, add this config to your parent POM (in a testing profile if you want):

<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>

Now, tell Maven these are test resources. If your test resource elements are consistent across the modules, this can go in the parent too, if they are different it goes in the module POM. (In my experience with Maven 3 resources defined in a child project take precedence over the parent's; they aren't merged.)

<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>

In the child module, define the resources module property (this is module a):

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

Adapt this to meet your use case.

---- Edit ----

If the configuration is placed into a parent POM, the parent POM may fail to build depending on what configuration is provided by the child. When we are building the shared base/parent projects we don't want to require that all of the properties that should be provided by child projects (inheriters) are defined. So we activate this profile when building the shared projects to bypass anything that only applies to children.

To do this, add an empty file pom-packaging.marker to the parent project's basedir. Then add this profile to the parent POM. When the parent project is built, Maven will find the marker file, enable the profile, and disable all of the executions included in the profile. When a child project is built, the marker file doesn't exist, so the configuration in the main part of the POM will take effect.

I've used this technique with the Enforcer plugin as well - the parent defines the enforcer rules that should be applied to projects inheriting from the parent, but cannot satisfy the rules when it is built. If the plugin provides a "skip" property, you may enable that in this profile instead of using phase = none in plugin configuration.

<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>