Sharing common resources between non-JAR maven projects

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

When you say "test config" is that plugin configuration, or separate configuration files for JMeter? — user944849, Jul 12 '12 at 17:41
As an alternative to protect inheritance, you could create another project with the config in, and use it in your parent as a dependency with scope "import" — Conan, Jul 12 '12 at 18:32
@user944849: the latter, I've now edited the question to make it clearer. — mikołak, Jul 12 '12 at 18:37
@Conan: could you post it as an answer and elaborate? Also, I'm not sure if it affects your answer, but I probably should point out that I'm using the `parent` project to inherit some Maven configuration such as plugins and properties. — mikołak, Jul 12 '12 at 18:39

user944849 · Accepted Answer · 2014-12-10T22:28:01.730

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>

This basically forces you to use the `jar` artifact type 'though, right? — mikołak, Jul 16 '12 at 16:04
Jar is the type of the shared resource project (a separate project you create) because that's what the `remote-resource` plugin builds. The modules that are using the shared resource project may have any type you want. I have used this pattern to include shared resources for projects with type `pom` before. Suggest giving it a try, run mvn with -X using different phases on cmd line and take a look at the target folder to see the result. — user944849, Jul 16 '12 at 17:13
You're right, it's not really that much of a problem since only the "resource" project has to be `jar`. I'll give it one more try. — mikołak, Jul 16 '12 at 20:00
I tried to adopt this solution, but get the error: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (load-resources) on project Parent: Resources archive cannot be found. This looks correct, as maven tries to build the parent pom first, i.e. the shared resources project needs to be next to the current parent, not under it to be build before the parent, right? — jan, Jul 04 '14 at 08:42
I added more to this answer to cover how I've worked around @jan's issue before. — user944849, Jul 07 '14 at 14:38
@user944849 I got it. Slightly complex, but very clever. I simply added one more pom module hierarchy. This is easier in this specific situation, but if one has more general resource sharing your solution is more elegant I think. — jan, Jul 09 '14 at 07:31

score 0 · Answer 2 · edited Dec 14 '12 at 20:24

0

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

edited Dec 14 '12 at 20:24

djechlin

59,258
35
162
290

answered Jul 13 '12 at 08:32

Conan

2,288
1
28
42

No need to apologize :). However, I'm not sure the `import` scope is supposed to allow for referencing *files* within a project, the page you linked indicates it's only for dependency management, quote: "projects can import managed dependencies from other projects. This is accomplished by declaring a pom artifact as a dependency with a scope of "import"." – mikołak Jul 16 '12 at 16:06
Ah I see, yes you're right. I guess you'd have to package up the shared resources in a new artifact, in which case you might as well just depend on that. In the past I've found it's quite neat to have shared test code in a separate library, and I see no reason you couldn't package shared config in the same way. – Conan Jul 17 '12 at 08:36
That's right, and I see no problem with creating a separate project (that's what I usually do with common **code**), however the requirement here is being able to reuse common non-code resources in a non-`jar` project. – mikołak Jul 17 '12 at 09:07
1

Yeah, without having access to a convenient Java classpath then packaging these resources inside a jar or similar isn't much good, because you'd then have to unzip the jar later in order to read them. You could just install the shared JMeter config file to Maven directly using `mvn install:install-file -Dfile= -DartifactId=shared.jmeter.properties -DgroupId= -Dversion=1.0 -Dpackaging=properties`, and then add it as a dependency. That's ok for one file, but it wouldn't help if you had multiple shared files, so it's not a complete solution. Worth a try? – Conan Jul 17 '12 at 13:05

Sharing common resources between non-JAR maven projects

2 Answers2

Linked