Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Let's say the "data" module is time consuming to build and we want to exclude it when the project is build by a CI server. Currently we use two pom.xml files to achieve this. One has all modules in it and the other one has all modules except the ones which can be left out for CI. But that's pretty annoying because sometimes we forget to put a new module into both files.

Is there a solution which doesn't need two separate module lists?

With Maven 3.2.1, you can now use -pl '!<module_name>,!<module_name>' to exclude certain modules from the reactor build:

mvn install -pl '!:module1,!:module2'
See this feature request: https://issues.apache.org/jira/browse/MNG-5230
                Don't forget to escape the exclamation mark on the shell command line. It has a very special meaning, see e.g. unix.stackexchange.com/questions/3747/…
– Pavel
                Apr 28, 2015 at 9:30
                You have to give like -pl [groupId]:artifactId, eg.  mvn clean install -pl !com.test:demoproject
– theNextBigThing
                Jun 15, 2021 at 8:37
                The only problem is that if you run it in Linux, it'll be treated as one of bash command switches, so to workaround that, I have to use the colon such as -pl "-:module-name"
– Wins
                Mar 1, 2022 at 0:44
                This worked for me - mvn package -pl '!server' . Need to escape the exclamation mark using single quotes.
– Loner
                Sep 13, 2022 at 9:53
                Whay would you do if you need data to happen prior to common?  In this case the profile modules will be placed after the default modules in reactor order.   Is there a pattern for forcing order?
– Peter Kahn
                Jun 7, 2012 at 17:33
                The order of module is NOT the order in which they will appear in the reactor. The only way to affect the order, is to create dependencies between modules, i.e. using the <dependency> tag. You cannot rely on the declaration order for this.
– SaM
                Jun 11, 2012 at 12:46
                @SaM Actually, as of Maven 3.0.5 the Reactor will take in account the order in 'modules', although the order dictated by dependencies is of a higher priority.
– hellodanylo
                Jul 29, 2013 at 11:23
                This will break some other plug-ins who fail to detect the module in the profile even the profile is enabled
– tribbloid
                Sep 30, 2015 at 21:49
The projects to build can also be specified on the mvn command line. This would remove the need for a separate pom, but instead you would have to change the CI configuration everytime there is a new module.
-pl,--projects <arg>                Comma-delimited list of specified
                                    reactor projects to build instead
                                    of all projects. A project can be
                                    specified by [groupId]:artifactId
                                    or by its relative path.
Maybe a combination of this flag and --also-make-dependents or --also-make would reduce this maintenance burden again.
-am,--also-make                     If project list is specified, also
                                    build projects required by the
-amd,--also-make-dependents         If project list is specified, also
                                    build projects that depend on
                                    projects on the list
                This has the same problems as using two separate poms. We have to places where we define the modules. That's what I'm trying to avoid.
– kayahr
                Apr 4, 2011 at 14:38
                This is a good solution. Don't have to update the pom. mvn clean install -pl mysubproject
– nicolas-f
                Apr 17, 2015 at 12:15
I assume you want the default build to always build everything, regardless of speed, so that new developers can get started quickly without having to understand lots about the POM. You can use profiles like this:
<modules>
    <module>common</module>
    <module>foo</module>
    <module>bar</module>
  </modules>
  <profiles>
    <profile>
      <id>expensive-modules-to-build</id>
      <activation>
         <activeByDefault>true</activeByDefault>
      </activation>
      <modules>
        <module>data</module>
      </modules>
    </profile>
  </profiles>
</project>
The problem with this is that if a developer specifies another profile on the command line, then the expensive-modules-to-build isn't included (unless the developer also specifies it). This makes it complicated to remember which profiles need to be included.
Here is a hacky way around that. Both profiles are always included, because the pom.xml file always exists. So to exclude the expensive modules, you can use -P!full-build on the command line.
<profiles>
    <profile>
        <id>full-build</id>
        <activation>
                <exists>pom.xml</exists>
            </file>
        </activation>
        <modules>
            <module>data</module>
        </modules>
    </profile>
    <profile>
        <id>short-build</id>
        <activation>
                <exists>pom.xml</exists>
            </file>
        </activation>
        <modules>
           <module>common</module>
           <module>foo</module>
           <module>bar</module>
        </modules>
    </profile>
</profiles>
                Nice answer. But do you really need two profiles in the 2nd code example? Wouldn't the single profile from the 1st code example with a changed activation element work?
– Arend v. Reinersdorff
                Oct 7, 2015 at 11:52
                @Arendv.Reinersdorff yes it would, however this answer also works with other profiles in the build that you may want to include by default. Overall though, I think the other answer with  -pl !<module_name>,!<module_name> is better than this old one
– artbristol
                Oct 7, 2015 at 17:13
                Good activation trick. It solved me the problems with <activeByDefault> that isn't always active!
– Gab
                May 10, 2016 at 1:28
                just adding that the <modules> section in the root <profiles> element can be skipped entirely, to be put into the individual <profile> section as above, in whatever combination is needed - this way you only have to specify the profile during the Maven build.
– hello_earth
                Aug 5, 2022 at 6:27
Another idea: Reactor modules can be nested, so it should be possible to group your fast and slow-building modules into separate poms and then add another aggregator pom containing these two as modules. Your CI Server could then only reference the pom containing the fast building modules.
<artifactId>fast</artifactId>
<modules>
    <module>fast-a</module>
    <module>fast-b</module>
    <module>fast-c</module>
</module>
<artifactId>all</artifactId>
<modules>
    <module>fast</module>
    <module>slow</module>
</module>
You could be to use maven profiles. In our build environment, we created a profile quick that disables many plugins and test execution.
This is done by 
    <profile>
        <id>quick</id>
        <properties>
            <skipTests>true</skipTests>
            <!-- others... -->
        </properties>   
        <build>
            <plugins>
                 <!-- configuration... -->
            </plugins>
        </build>
    </profile>
And then we invoke maven the following way
mvn groupId:artifactId:goal -P quick
You could maybe disable compilation and other standard plugins in the pom of your module to speed it up. 
                Yes, for disabling tests this works great. But how can I use profiles to exclude modules WITHOUT having two separate modules lists in the pom? As far as I know I need to put the full module list into one profile section and the quick-build module list into an other profile section. So this has the same problem as using two separate poms: I have two module lists to maintain.
– kayahr
                Apr 4, 2011 at 14:40
                Excluding module is not really the way to do things in maven and my experience with maven is that is better to stick with the way things are done, else you run in so many problems... So really what I'm proposing is not to remove the module, but to make this module less time consuming.
– Nr9
                Apr 4, 2011 at 14:49
                The problem with maven is that 'the way things are done' is frequently not in alignment with 'the way things are done in the real world', making the maven experience poor and painful.  The developers would do well to take a dose of UX training.
– Ed Randall
                Jan 9, 2018 at 10:44
Not exactly the answer these folks were asking for. My situation was I wanted to deploy only the parent pom. I'm using the spring-boot-thin-layout in a child module. This requires the parent module be deployed into artifactory. I added the following into my project. It enables skipping of install and/or deploy phase.
In my parent pom:
<properties>
    <disable.install>true</disable.install>
    <disable.deploy>true</disable.deploy>
    <enable.deployAtEnd>true</enable.deployAtEnd>
</properties>
<profiles>
    <profile>
        <id>deploy-parent</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <disable.install>true</disable.install>
            <disable.deploy>true</disable.deploy>
            <deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
        </properties>
        <build>
            <finalName>${project.version}</finalName>
        </build>
    </profile>
</profiles>
And the in my child pom(s) or any module you don't want deployed with parent:
<properties>
    <maven.install.skip>${disable.install}</maven.install.skip>
    <maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
    <deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
So effectively when I run mvn deploy on the parent pom, it will compile all the modules, not run install on anything, and then at the end deploy any module not having <maven.deploy.skip>${disable.deploy}</maven.deploy.skip> in it's properties. So in my case only deploying the parent. 
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.