wombatu-kun opened a new pull request, #19020: URL: https://github.com/apache/hudi/pull/19020
### 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. ### 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. 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; any module that overrides the compiler `<configuration>` simply keeps today's classpath discovery. 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](https://hudi.apache.org/contribute/how-to-contribute) - [ ] Enough context is provided in the sections above - [ ] Adequate tests were added if applicable -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
