yihua opened a new pull request, #20238: URL: https://github.com/apache/hudi/pull/20238
### Describe the issue this Pull Request addresses closes #20237 Under `-DdeployArtifacts=true` (used by the `validate-bundles` CI job and by releases), `javadoc:jar` fails on `hudi-spark-client` and `hudi-spark-common` because their Java sources import Scala classes compiled in the same module. The javadoc plugin only puts dependency artifacts on javadoc's classpath, never the module's own output, so those symbols never resolve. `failOnError=false` keeps the build green, but every PR gets the errors as check annotations on files it never touched. ### Summary and Changelog In the `deployArtifacts` profile, feed the module's own jar back to javadoc through `additionalDependencies` (system scope, `systemPath` pointing at the jar that `jar:jar` builds earlier in the package phase). This mirrors how references to Scala classes in other modules already resolve through dependency jars. Verified with the CI-equivalent `mvn clean package -T 2 -DdeployArtifacts=true -DskipTests` run locally: zero javadoc errors across all modules, and the `hudi-spark-client` javadoc jar now contains the previously failing classes. ### Impact Build only. Published javadoc jars for the mixed Scala/Java modules become complete; no runtime change. ### Risk Level low. If a module's jar were missing when javadoc runs, the plugin would log a resolution error and continue, as it does today for the failing modules. ### Documentation Update none ### Contributor's checklist - [x] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [x] Enough context is provided in the sections above - [x] 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]
