|
Currently (3.0.4) Apache Maven doesn't support incremental builds very well. Because of that fact, most people use mvn clean compile
instead of mvn compile
for example. This is pretty time consuming and can be improved a lot.
The goal is to make mvn compile
, mvn verify
, mvn install
, ... (all stuff without clean
) usable for almost all situations.
In general it's better we unnecessarily force a bit more work than to not detect a change as in the later case we would end up with broken artifacts and people will use the clean
goal again.
check out the sample project
git clone git://github.com/struberg/maventest.git |
First please set the maven-compiler-plugin version back to 2.5 (the latest release). Then build the whole project with
mvn clean install |
Now change the code of BeanA and rename getI()
to getI_doesntexistanymore()
. This means that BeanA2.java as well as BeanB.java should fail to compile!
But if we try to build the project with
mvn install |
without any clean lifecycle, then we see 2 bugs
And this is just the tip of the iceberg.
In maven this needs 2 parts to get tweaked.
The following parts should be implemented in the maven-core reactor code (or what remained from it). If any of those tests indicate a change then we force a 'clean' on the module and on all depending downstream modules.
Each plugin need to check on it's own whether it should perform it's tasks or not. Not every plugin needs the full dependency graph. And other plugins (e.g. maven-ear-plugin) even have 'manual' dependencies which are not reflected in the dependency graph. Thus all plugins need to check for themselfs whether they need to do something or not. The first plugin which kicks in detecting a change will create a result. And this result might trigger work in another plugin/phase.
A plugin has a few ways to detect that it needs to do some work
It's suggested that all those additional information will get stored in ./target/maven.status/${plugin-name}.status