Date: Tue, 19 Mar 2024 11:23:00 +0000 (UTC) Message-ID: <1445566639.56391.1710847380067@cwiki-he-fi.apache.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_56390_775670781.1710847380067" ------=_Part_56390_775670781.1710847380067 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Currently (3.0.4) Apache Maven doesn't support incremental builds very w=
ell. Because of that fact, most people use mvn clean compile
i=
nstead of mvn compile
for example. This is pretty time consumi=
ng and can be improved a lot.
The goal is to make mvn compile
, mvn verify
, <=
code>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 no=
t detect a change as in the later case we would end up with broken artifact=
s 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 late= st release). Then build the whole project with
mvn clean ins= tall
Now change the code of BeanA and rename getI()
to get=
I_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 w= e 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 tas= ks or not. Not every plugin needs the full dependency graph. And other plug= ins (e.g. maven-ear-plugin) even have 'manual' dependencies which are not r= eflected in the dependency graph. Thus all plugins need to check for themse= lfs 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 w= ork 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