Motivation
SpotBugs in particular is slow (~1m22s on a 14-core Mac for the full reactor; longer on the 4-core CI runner). On a typical PR that touches one plugin, only that plugin's analysis is genuinely needed — the rest is noise that delays feedback. PMD and Checkstyle add roughly the same proportional overhead.
A "run only what changed" workflow would substantially shrink the static-analysis job's wall-clock time on most PRs.
Options
1. gitflow-incremental-builder (recommended)
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder — Maven core extension, registered in .mvn/extensions.xml. Detects which modules changed since a configurable git ref (e.g. origin/master) via git diff and skips unchanged modules entirely from the reactor. Standard option used by many large multi-module Java projects.
- No POM edits, no manual skip toggles per plugin
- Configurable base ref, behaviour for transitively-affected modules, etc.
- Works with any Maven goal (compile, pmd:check, spotbugs:check, ...)
- Plays well with Tycho
2. takari-lifecycle-plugin
https://github.com/takari/takari-lifecycle-plugin — incremental Maven that replaces the standard build lifecycle with a hash-based one. Heavier than (1); affects more of the build, not just module skipping.
3. mvn -amd + manual -pl from git diff
Maven 4's --also-make-dependents plus explicitly listing changed modules from a git diff --name-only ... | xargs ... script. No extension required, but every workflow has to script the module list itself.
Suggested next step
Trial (1) on a branch: register gitflow-incremental-builder in .mvn/extensions.xml with origin/master as the reference branch, then measure CI wall-clock on a typical single-plugin PR vs a master-touching PR. If the speedup is meaningful and Tycho compatibility holds, adopt it for the static-analysis (and possibly maven-verify) jobs.
Caveat
Pin to a specific version, audit for the project's CI sandboxing constraints, and verify behaviour around generated sources (Xtend/Xtext gen) — those may need explicit inclusion to avoid being treated as unchanged.
Motivation
SpotBugs in particular is slow (~1m22s on a 14-core Mac for the full reactor; longer on the 4-core CI runner). On a typical PR that touches one plugin, only that plugin's analysis is genuinely needed — the rest is noise that delays feedback. PMD and Checkstyle add roughly the same proportional overhead.
A "run only what changed" workflow would substantially shrink the static-analysis job's wall-clock time on most PRs.
Options
1.
gitflow-incremental-builder(recommended)https://github.com/gitflow-incremental-builder/gitflow-incremental-builder — Maven core extension, registered in
.mvn/extensions.xml. Detects which modules changed since a configurable git ref (e.g.origin/master) viagit diffand skips unchanged modules entirely from the reactor. Standard option used by many large multi-module Java projects.2.
takari-lifecycle-pluginhttps://github.com/takari/takari-lifecycle-plugin — incremental Maven that replaces the standard build lifecycle with a hash-based one. Heavier than (1); affects more of the build, not just module skipping.
3.
mvn -amd+ manual-plfrom git diffMaven 4's
--also-make-dependentsplus explicitly listing changed modules from agit diff --name-only ... | xargs ...script. No extension required, but every workflow has to script the module list itself.Suggested next step
Trial (1) on a branch: register
gitflow-incremental-builderin.mvn/extensions.xmlwithorigin/masteras the reference branch, then measure CI wall-clock on a typical single-plugin PR vs a master-touching PR. If the speedup is meaningful and Tycho compatibility holds, adopt it for the static-analysis (and possibly maven-verify) jobs.Caveat
Pin to a specific version, audit for the project's CI sandboxing constraints, and verify behaviour around generated sources (Xtend/Xtext gen) — those may need explicit inclusion to avoid being treated as unchanged.