Sharing resources between non-JAR maven projects

Question

I have several Maven projects, say a , b , c , inheriting from one parent (let them call it parent ), and are also modules (of a project other than parent , call it super ).

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

The problem is how to configure POM so that the shared configuration file is shared between projects?

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

There are similar questions like this one , but they are dealing with a jar plugin that is not relevant to this case.

Structure, for reference:

• POM Inheritance:

    parent | ------------- | | | abc 

• File structure:

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

Answer 1

I used maven-remote-resources-plugin for a similar purpose. Create a separate resource 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 instructions in example to create the package.

Now add this configuration to the parent POM (if you want, to the testing profile):

 <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 that these are test resources. If the elements of the test resource are consistent between the modules, this can also go to the parent, if they differ, then it is in the POM module. (In my experience with Maven 3 resources defined in a child project, priority over parent is not combined.)

 <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 property of the resource module (this is module a):

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

Adapt it to suit your use case.

---- Edit ----

If the configuration is placed in the parent POM, the parent POM may not be created depending on the configuration provided by the child. When we create common base / parent projects, we do not want to require that all properties that should be provided by child projects (inheritors) be defined. Therefore, we activate this profile when creating common projects in order to get around everything that applies only to children.

To do this, add the empty pom-packaging.marker file to the pom-packaging.marker basedir project. 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 executions included in the profile. When the child project is built, the marker file does not exist, so the configuration in the main part of the POM will take effect.

I also used this method with the Enforcer plugin - the parent defines enforcement rules that should apply to projects inherited from the parent, but cannot satisfy the rules when it is built. If the plugin provides the "skip" property, you can enable it in this profile, and not use the phase = not in the 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> 

Answer 2

The idea with import scope dependencies is that you can put the shared resources into a separate project, which is then imported along with a number of others; I thought you could include your shared configuration file this way.

You create a new project with pom packaging (perhaps at the same level as the parent?), And then include it in the parent dependencyManagement section with the import scope. Each of your affiliated projects can inherit it. It may seem redundant to make an entire project for just one file, but I would not have a problem with that.

I actually haven't tried this with the pom packaged projects tree, so you might have to play a little, but an approach that seems to me to sound. Here's a (very extensive) example:

Import Dependencies