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

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

Hi,

Sounds a very good move, my 2 cts would be

1. while it ends in the new API it is great
2. why reflection since descriptor is in mem at some point? +1 to be able
to tune it with a dedicated API
3. while documented yes IMHO

side note: how would we make compilation incremental with annot proc?
dedicated API as gradle? should we lean toward an unified api?

Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> |=
 Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-97817884=
73064>
Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via
linkedin)


Le lun. 3 ao=C3=BBt 2026 =C3=A0 14:14, Guillaume Nodet <gnodet.apache@gmail=
.com> a
=C3=A9crit :

> 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 start=
ed
> 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 =
old
> 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 fr=
ee without
> implementing their own checks.
>
> Performance
>
> Benchmarked against stock 3.x plugins on a 20-module reactor (4000 source=
s,
> 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=
 for
> 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 o=
pt-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
>

--0000000000007f77660658257549--