Configure Maven plugins to stick together.

Question

I have parent pom which configures certain plugins

<pluginManagement>
   </plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
         ...
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
         ...
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
         ...
      </plugin>
   </plugins>
</pluginManagement>

And I have tree of poms which are represent integration tests

A-\
   a1
   a2
B-\
   b1
   b2
C-\
   D-\
      d1
      d2

In each a,b,d products I do

<build>
   <plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
      </plugin>
   </plugins>
</build>

The problem is when I will need to add fourth plugin to integration test process for example my custom plugin I will need to move through all of the integration modules and do manual adding.

You can advice me to remove <pluginManagement> to allow all child just to use them implicitly. Yes, but in products which are just 'pom' I don't want plugins to do anything: create some resources and put jboss configuration directories.

I wonder is there some kind of

<pluginsBundle>
   <groupId>my.group</groupId>
   <artifactId>my-integration-test-bundle</artifactId>
   <plugins>
      <plugin>
         <artifactId>gmaven-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>maven-resources-plugin</artifactId>
      </plugin>
      <plugin>
         <artifactId>cargo-maven2-plugin</artifactId>
      </plugin>
   </plugins>
</pluginsBundle>

To allow me use it just like

   <plugin>
      <groupId>my.group</groupId>
      <artifactId>my-integration-test-bundle</artifactId>
      <runOnce>true</runOnce>
   </plugin>

I would like to add option like

<runOnce>true</runOnce>

to be able to start application server and deploy target only one time per maven launch.

Answer 1

AFAIK, there is no way to declare a bundle of plugins that could be used somewhere else... but there is inheritance.

What about creating a pom with the <plugins> declaration in the <build> section and inheriting from this pom in your integration tests projects? This looks like feasible.

Answer 2

I don't know of a mechanism that does exactly what you need. Your best bet is to define a parent pom with those plugins defined in the build section, rather than the pluginManagement section. In this case the plugin configuration will always be defined. Adding the configuration to a profile in the parent means you can exercise some control over the activation of those plugins.

One refinement to consider is that you can control activation of a profile by the presence or absence of a file. This way you can define the profile in the parent, but have it deactivated in that project because of the marker file being present in the parent. Child projects would not have the marker file in their source, so the profile would be activated for those projects. You can reverse the behaviour by using missing instead of exists if that makes sense for the majority of projects.

<profile>
  <id>build</id>
  <activation>
    <file>
      <missing>src/main/resources/build.marker</missing>
      <!-- or if you want to enable the profile when the file does exist:
      <exists>src/main/resources/build.marker</exists-->
    </file>
  </activation>
  <build>
    </plugins>
      <plugin>
        <artifactId>gmaven-plugin</artifactId>
        ...
      </plugin>
      <plugin>
        <artifactId>maven-resources-plugin</artifactId>
        ...
      </plugin>
      <plugin>
        <artifactId>cargo-maven2-plugin</artifactId>
        ...
      </plugin>
    </plugins>
  </build>
</profile>

---

Alternatively, you could try writing custom plugin with a lifecycle that executes all the required mojos in a forked lifecycle. I recently answered another question with details of how to do this.

Another alternative is to write another plugin that uses Maven shared-io to apply a descriptor to the pom, that descriptor can define arbitrary configuration that is merged into the pom. Another answer describes how this can be done.