How do I configure my Maven-war-plugin's useCache feature so that consecutive builds are faster?

I’m using Maven 3.3.0 on Mac Yosemite. I wanted to make use of the maven-war-plugin’s useCache feature, but it isn’t doing anything in my multi-module project. When I run

mvn clean install -DskipTests

my project takes about 1:25 to run with the below configuration

<profile>
    <id>prepare-deploy-war-to-jboss</id>
    <activation>
        <file>
            <exists>${basedir}/src/main/webapp</exists>
        </file>
    </activation>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <useCache>true</useCache>
                    <cacheFile>/tmp/${project.artifactId}/war/work</cacheFile>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

Then I run the same command again and the project takes the same amount of time. I can see “work” files getting created so the plugin is definitely running but consecutive builds do not seem to be doing anything.

My question here isn’t so much as why isn’t useCache speeding up my build, but how can I configure my plugin differently so that consecutive runs do speed up the build? If there is another plugin I should be using that would speed up builds on back-to-back runs, then that would also suffice here.

Looking at the WAR mojo code (at the time of writing), the cache is mainly used by its web app structure concerning overlays management, so in most of the cases it would not improve build time indeed.

Moreover, as stated by its official documentation, the cache mechanism is an experimental feature, hence disabled by default, which probably doesn't achieve (yet) user expectations.

---

Regardless of the effectiveness of this cache option, some hints to speed up maven builds could be:

• Consider whether you really need to clean at each and every run
• Consider building offline (-o option) if everything you need is already on your local cache
• Consider using threads during your build (-T option)
• Consider going on quite mode (-q option), swithing off build log temporarely and getting only error logs (basically: no news, good news)
• In your case, the War Plugin is activated upon the existence of a structure typical of a war packaging, which probably means this profile is part of the aggregator/parent pom and then activated only on the war module. Although it might impact very little, also consider moving the War Plugin configuration to its concerned module and avoid such a triggered configuration

---

Last but not least, during development time, build time is probably more important than war size, so you could switch off the default mechanism of re-compressing external libraries added to the war file, via the recompressZippedFiles option:

Indicates if zip archives (jar,zip etc) being added to the war should be compressed again. Compressing again can result in smaller archive size, but gives noticeably longer execution time.
Default: true

So a sample configuration would look like:

<properties>
    <war.recompress.files>false</war.recompress.files>
</properties>

<build>
    <finalName>webapp</finalName>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.6</version>
            <configuration>
                <recompressZippedFiles>${war.recompress.files}</recompressZippedFiles>
            </configuration>
        </plugin>
    </plugins>
</build>

Note: since there is no user property for this configuration entry, I also added a property for it, to switch it on/off on demand via command line (or via profile).

You could then test the different execution times executing the default build (with the configuration above disabling recompression) against the previous configuration (below, switching recompression on for the current execution, on demand):

mvn clean install -Dwar.recompress.files=true

You may then consider to profile it to switch it on/off depending on development phase.