Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8713607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 13, 20262026-06-13T05:22:58+00:00 2026-06-13T05:22:58+00:00

I have a set of projects which all need to run the same series

  • 0

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

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-13T05:23:00+00:00Added an answer on June 13, 2026 at 5:23 am

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

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I have all php tools set up for Jenkins php projects. I set up
I have set up my maven project using the m2e plugin in eclipse indigo,
I have a zendframework project for which i need to run a script periodically
I have findbugs plugin for eclipse which when run on my project will show
I have a project which has a set of binary dependencies (assembly dlls for
I have a Visual Studio Setup project which has a Application Folder DefaultLocation set
I have to set a few projects in our VS 2005 solution to build
Just starting out with subversion, have set up repos for 3 current projects and
I have Visual Studio 2003 project and I have set all of the AssemblyInfo
Background I have a bunch of students, their desired projects and the supervisors for

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.