Define Maven plugins in parent pom, but only invoke plugins in child projects

Question

I have a set of projects which all need to run the same series of Maven plugin executions during their builds. I'd like to avoid re-declaring all of this configuration in every project, so I made them all inherit from a parent pom "template" project which only contains those plugin executions (8 different mojos). But I want those plugin executions to only run on the child projects and not on the parent project during Maven builds.

I've tried to accomplish this four different ways, each with a side-effect I don't like.

1. Declare the plugin executions in the parent pom's build/plugins element and use properties-maven-plugin to turn on the skip properties on other plugins in the parent project. This didn't work because one of the plugin goals (maven-dependency-plugin:build-classpath) doesn't have a skip property.

2. Declare the plugin executions in the parent pom's build/pluginManagement element. Unfortunately this requires me to redeclare each of the eight plugins in the build/plugins element of every child project's pom like:

   <plugin>
       <artifactId>maven-assembly-plugin</artifactId>
   </plugin>
   ...
   

   This is too repetitive, and problematic if I ever need to change the plugins in the template pom.

3. Declare the plugin executions in a profile in the parent pom which is activated by the lack of a nobuild.txt file (which does exist in the parent pom, so the plugins don't execute there):

   <profiles>
       <profile>
           <activation>
               <file>
                   <missing>nobuild.txt</missing>
               </file>
           </activation>
           <build>
               ....
           </build>
       </profile>
   </profiles>
   

   This works for the most part, except that the file path in the missing element seems to be based on the current working directory instead of the project basedir. This breaks some of the multimodule builds I'd like to be able to do. Edit: to clarify, the parent "template" project is actually itself a module in a multimodule project, and the build breaks when I try, for instance, to do a mvn install on the root. The project structure looks like:

   + job
   |- job-core
   |- job-template
   |- job1                   inherits from job-template
   |- job2                   inherits from job-template
   

4. Set up a custom lifecycle and packaging. This seems to allow me to bind plugins to lifecycle phases, but not specify any configuration.

So, is there another way to specify a bunch of Maven plugin executions that can be reused across several projects (with minimal repetition in each of those projects' poms)?

Answer 1

Here's the fifth way. I think it has minimum drawbacks: no profiles, no custom lifecycle, no declarations in child POMs, no 'skip' requirement for plugins.

Copied it from https://stackoverflow.com/a/14653088/2053580 -- many thanks to end-user!

<build>
    <pluginManagement>
        <plugins>
            <plugin>
                <!-- Main declaration and configuration of the plugin -->
                <!-- Will be inherited by children -->
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>2.9.1</version>
                <executions>
                    <execution>
                        <!--This must be named-->
                        <id>checkstyle</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
                <!-- You may also use per-execution configuration block -->
                <configuration...>
            </plugin>
        </plugins>
    </pluginManagement>
    <plugins>
        <plugin>
            <!-- This declaration makes sure children get plugin in their lifecycle -->
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <!-- Configuration won't be propagated to children -->
            <inherited>false</inherited>
            <executions>
                <execution>
                    <!--This matches and thus overrides execution defined above -->
                    <id>checkstyle</id>
                    <!-- Unbind from lifecycle for this POM -->
                    <phase>none</phase>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Answer 2

I ended up writing my own plugin which utilizes mojo-executor to invoke other mojos. This allows me to 1) centralize the build configuration and 2) minimize the amount of configuration that gets duplicated in each of the child projects.

^{(In case you are curious about the reason for all of this: each child project is a job which will be executed from the command line. The build sets up an invoker shell script and attaches it to the build so it gets checked into our artifact repository. A deploy script later pulls these down onto the machine they will run on.)}

Relevant parts of the template project's pom:

<project ...>
    <parent> ... </parent>
    <artifactId>job-template</artifactId>
    <packaging>pom</packaging>
    <name>job project template</name>
    <build>
        <pluginManagement>
            <plugin>
                <groupId>...</groupId>
                <artifactId>job-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>generate-sources-step</id>
                        <goals><goal>job-generate-sources</goal></goals>
                    </execution>
                    <execution>
                        <id>package-step</id>
                        <goals><goal>job-package</goal></goals>
                    </execution>
                    ... (a couple more executions) ...
                </executions>
            </plugin>
        </pluginManagement>
    </build>
</project>

Had to create a new maven-plugin project (job-maven-plugin). Pom looks like:

<project ...>
    <parent> ... </parent>
    <artifactId>job-maven-plugin</artifactId>
    <packaging>maven-plugin</packaging>
    <name>job maven executor plugin</name>
    <dependencies>
        <dependency>
            <groupId>org.twdata.maven</groupId>
            <artifactId>mojo-executor</artifactId>
            <!-- version 1.5 supports Maven 2, while version 2.0 only supports Maven 3 -->
            <version>1.5</version>
        </dependency>
    </dependencies>
</project>

As you can see from the template project, there were multiple mojos in my plugin (one per phase that needed stuff to happen). As an example, the job-package mojo is bound to the package phase and uses the mojo-executor library to run two other mojos (which just attach some build artifacts):

/**
 * @goal job-package
 * @phase package
 */
public class PackageMojo extends AbstractMojo {
    /**
     * @parameter expression="${project}"
     * @required
     * @readonly
     */
    protected MavenProject project;
    /**
     * @parameter expression="${session}"
     * @required
     * @readonly
     */
    protected MavenSession session;
    /**
     * @component
     * @required
     */
    protected PluginManager pluginManager;

    @Override
    public void execute() throws MojoExecutionException, MojoFailureException {
        ExecutionEnvironment environment = executionEnvironment(project, session, pluginManager);

        // Attach script as a build artifact
        executeMojo(
            plugin(
                groupId("org.codehaus.mojo"),
                artifactId("build-helper-maven-plugin"),
                version("1.7")
            ),
            goal("attach-artifact"),
            configuration(
                element("artifacts",
                    element("artifact",
                        element("file", "${project.build.directory}/script.shl"),
                        element("type", "shl")
                    )
                )
            ),
            environment
        );

        // Zip up the jar and script as another build artifact
        executeMojo(
            plugin(
                groupId("org.apache.maven.plugins"),
                artifactId("maven-assembly-plugin"),
                version("2.3")
            ),
            goal("single"),
            configuration(
                element("descriptors",
                    element("descriptor", "${project.build.directory}/job/descriptor.xml")
                )
            ),
            environment
        );
    }
}

Then, in the child projects, I just have to refer to the plugin once. In my opinion, this is greatly preferable over reiterating each of the behind-the-scenes plugins in every child project (which unacceptably increases the coupling between poms). If I want to add a mojo execution to the build procedure in the future, I only have to modify one place and bump a version number. Child project's pom looks like:

<project ...>
    <parent>
        <groupId> ... </groupId>
        <artifactId>job-template</artifactId>
        <version> ... </version>
        <relativePath>../job-template</relativePath>
    </parent>
    <artifactId>job-testjob</artifactId>
    <name>test job</name>
    <build>
        <plugins>
            <plugin>
                <groupId> ... </groupId>
                <artifactId>job-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

Also, the entire multimodule directory structure now looks like this:

+- job
  +- job-core
  +- job-maven-plugin
  +- job-template
  +- job-testjob1               (inherits from job-template)
  +- job-testjob2               (inherits from job-template)

In my opinion this solution is not entirely optimal, since I now have plugin configuration embedded in a series of mojos instead of a pom, but it meets my goals for centralizing the configuration and minimizing the duplication among child project poms.

^{(One last note: I just discovered maven-aggregate-plugin which seems to allow grouping multiple plugin executions in the pom. This might have solved the problem in a slightly more desirable way, but I'm not in the mood to redo the last few hours of work. Might be beneficial to someone else though.)}

Answer 3

Personally I would go for solution 2. The repetition is minimal and you should try to avoid profiles if possible to avoid having to start documenting which profiles need to be activated for which projects.

A project should be able to be built correctly by simply doing a mvn (clean) install.