fix(build): declare lombok in annotationProcessorPaths to deflake parallel-build compilation

[wombatu-kun]

Describe the issue this Pull Request addresses

The parallel reactor build (mvn clean install -T 2) intermittently fails a module's testCompile with:

Bad service configuration file, or exception thrown while constructing Processor object:
javax.annotation.processing.Processor: Provider lombok.launch.AnnotationProcessorHider$AnnotationProcessor could not be instantiated

This is a flaky ServiceLoader race: the Lombok annotation processor is discovered from the shared compile classpath's META-INF/services file, and under a parallel (-T) build running in a single JVM that discovery/instantiation intermittently fails. It is unrelated to the code under test (it surfaced on hudi-cli while hudi-kafka-connect built fine). Seen in the test-common-and-other-modules job: https://github.com/apache/hudi/actions/runs/27601324605/job/81602759051

Summary and Changelog

Declare the annotation processor path explicitly in the parent maven-compiler-plugin configuration (<annotationProcessorPaths> with org.projectlombok:lombok:${lombok.version}) instead of relying on classpath service discovery. An explicit processor path gives each compilation a dedicated, isolated processor classloader, which removes the discovery race and also stops the compiler from scanning the whole compile classpath for processor service files.

Lombok is the only annotation processor that has any work in this build, verified by inspection: no @AutoService, Immutables, MapStruct, or log4j @Plugin annotations exist in the source and there are no custom META-INF/services/javax.annotation.processing.Processor files, so isolating Lombok does not disable any meaningful processing.

The configuration lives in the parent <pluginManagement>, so it applies to every module. The four modules that override the compiler <configuration> (hudi-common, hudi-hadoop-common, hudi-hadoop-mr, hudi-io, all only to target Java 8) still inherit annotationProcessorPaths through Maven's per-element configuration merge. This was verified with mvn help:effective-pom: their effective testCompile configuration contains both <release>8</release> and the lombok annotationProcessorPaths. No module declares its own annotationProcessorPaths, so coverage is global with this single change.

Impact

Build/CI reliability only; no product code, API, or behavior change. Reduces flaky testCompile failures caused by the processor-instantiation race under parallel builds, across all modules. Lombok processing itself is unchanged, verified by compiling a @Slf4j module (hudi-kafka-connect) cleanly under the new configuration.

Risk Level

low

Lombok is the only annotation processor with work in the repo, so making the processor path explicit is behavior-preserving for compilation, and effective-pom confirms every module (including the Java 8 ones that override the compiler config) keeps the processor path. Verified that a Lombok-using module compiles cleanly under the change. The flake is environmental and not locally reproducible, so this is the standard, recommended mitigation for the symptom rather than a locally-proven elimination.

Documentation Update

none

Contributor's checklist

• Read through contributor's guide
• Enough context is provided in the sections above
• Adequate tests were added if applicable

[hudi-bot]

CI report:

• e32edd9 Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build

[hudi-agent]

🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.

Thanks for the contribution! This PR declares Lombok explicitly in annotationProcessorPaths in the parent maven-compiler-plugin config to fix a flaky ServiceLoader race during parallel reactor builds. No issues flagged from this automated pass — a Hudi committer or PMC member can take it from here for a final review.

cc @yihua