Maven compiler plugin always detecting a set of sources as “stale”

Question

FIXED: this is a known bug in maven-compiler-plugin 3.1

I am converting an ant-based build of a 1000+ java-sources project to maven. So far so good, but every time l

Answer 1

I don't understand why, but the solution from tucuxi's answer doesn't work in my case. In my project there are thousands of files generated by special tool and its recompilation may waste really a lot of time.

I've tried the following plugin configuration (with java level 1.5):

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>
        <useIncrementalCompilation>true</useIncrementalCompilation>
    </configuration>
</plugin>

On a second run, there are no stale files was detected but the plugin recompiled all the project again. It seems that incremental compilation actually disabled by default, and still not working even if useIncrementalCompilation=true specified.

After some googling, I've simply changed useIncrementalCompilation parameter value from "true" to "yes" and this do the trick for me.

@see also stackoverflow.com/a/19653164/1848640

Answer 2

If you're sure there's been no change, you can pass in -Dmaven.main.skip. I have a project where I do this after running Proguard, since it's the only way to reuse the Proguarded jar for tests. (NB: I run the same unit tests before Proguard as after, to make sure Proguard hasn't broken anything. To bring this as close to the standard Maven workflow as possible, I do the pre-Proguard run in Surefire and the post-Proguard run in Failsafe.)

Answer 3

This is a known problem in maven-compiler-plugin 3.1. It is being tracked in https://issues.apache.org/jira/browse/MCOMPILER-209 (the useIncrementalCompilation flag is broken).

The problem is unrelated to another 3.1 bug, https://issues.apache.org/jira/browse/MCOMPILER-205 (where files that do not produce .class outputs are always flagged as 'stale').

After testing further, going back to 3.0 did not actually fix the problem (it only works until the next mvn clean compile. However, as Michael Lemke suggests in comments, marking useIncrementalCompilation to false is a workable substitute; now, only the offending package gets recompiled each time (instead of the whole code-base).