[DISCUSS] Incremental Build Context API for Maven 4.1.0 (PR #12576)

--000000000000e9cd940658237b02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

I'd like to bring up the incremental build context work for discussion.

Background

This builds on a long lineage: the original plexus-build-api by Sonatype
(Igor Fedorenko), later evolved into Takari's io.takari.incrementalbuild
API, which powered m2e's incremental workspace builds in Eclipse. I started
porting this to Maven 4 in PR #1118 a while back; PR #12576 picks that up,
modernizes it to Maven 4 conventions (@MojoExecutionScoped DI,
@Experimental annotations, PathMatcherFactory reuse), adds performance
optimizations, and integrates it with four core plugins as proof-of-concept=
.

What it provides

A first-class API in maven-api-core for mojo authors to track input file
changes, associate inputs with outputs, skip execution when nothing
changed, and get automatic stale output cleanup =E2=80=94 all things the ol=
d
plexus-build-api did, but now as part of Maven's public API with an SPI
layer for IDE integration (workspace modes for m2e-style delta builds).

The framework automatically digests @Parameter fields and the plugin
classpath to detect configuration changes =E2=80=94 mojos get this for free=
 without
implementing their own checks.

Performance

Benchmarked against stock 3.x plugins on a 20-module reactor (4000 sources,
600 resources):

- No-op rebuild: =E2=88=9244% (15.7s =E2=86=92 8.7s)
- Single file change: =E2=88=9240%
- Delete + stale cleanup: =E2=88=9248%
- Clean build: +39% overhead (amortized after one incremental rebuild)

A -Dmaven.buildcontext.skip=3Dtrue property disables the context entirely f=
or
CI/release builds.

Plugin integrations

- maven-resources-plugin#496 + maven-filtering#363
- maven-jar-plugin#566
- maven-compiler-plugin#1096

Questions for discussion

1. Is o.a.m.api.build.context the right package home? (Chosen to avoid
collision with build report API in #12572)
2. Automatic @Parameter digestion via reflection =E2=80=94 should it be opt=
-in via
@Incremental instead?
3. The context is per-mojo-execution, no cross-module coordination.
Sufficient for a first iteration?

Main PR: https://github.com/apache/maven/pull/12576
Original PR: https://github.com/apache/maven/pull/1118

Feedback welcome.

Guillaume

--000000000000e9cd940658237b02--