voonhous opened a new issue, #19468: URL: https://github.com/apache/hudi/issues/19468
## Task Description **What needs to be done:** Add `hudi-presto-bundle` coverage to `packaging/bundle-validation`, exercised in a way that resolves its bundle dependencies from the repository rather than from the reactor. **Why this task is needed:** #19433 fixed a regression where `hudi-presto-bundle` silently shipped a jar containing **0** `org/apache/hudi/hadoop/**` entries instead of 109, losing `HoodieParquetInputFormat` -- the class the bundle exists to provide. Shade does not fail when an `artifactSet` include matches nothing, so the build stayed green and the jar just got quietly smaller. Nothing in CI could have caught that, for two independent reasons. **1. There is no presto coverage at all.** `git grep -il presto packaging/bundle-validation` returns nothing, and the same is true for `trino`. `validate.sh` exercises `hudi-cli-bundle`, `hudi-kafka-connect-bundle`, `hudi-metaserver-server-bundle`, `hudi-utilities-bundle` and the spark/flink bundles. Of the seven bundles touched by #19433, only `hudi-hadoop-mr-bundle` appears in `bundle-validation` at all -- `hudi-presto-bundle`, `hudi-aws-bundle`, `hudi-gcp-bundle`, `hudi-datahub-sync-bundle` and `hudi-hive-sync-bundle` have no stage. (The `azure` matches under that directory are the Azure Pipelines config, not `hudi-azure-bundle`.) **2. Even with a stage, `-am` would hide this class of bug.** Every `-pl packaging/...` invocation under `.github/workflows` and `scripts/` passes `-am` -- 10 out of 10 on master. With `-am` the dependency bundles are built in-reactor, and Maven's `ReactorReader` serves the effective model rather than the published dependency-reduced POM, so the resolution path that actually broke is never exercised. A stale un-reduced POM in `~/.m2` masks it the same way. Suggested minimum: a validation step asserting the presto bundle contains `org/apache/hudi/hadoop/HoodieParquetInputFormat.class`, built **without** `-am` so `hudi-hadoop-mr-bundle` resolves from the repository. A jar-entry count assertion would also have caught this specific regression, since the count went 109 -> 0. Worth considering more generally: a check that fails the build when a shade `artifactSet` include matches no artifact would catch this whole class of silent shrinkage across all 16 bundles, rather than one bundle at a time. ## Task Type Test enhancement ## Related Issues **Parent feature issue:** #16407 **Related issues:** #19433, #19466 -- 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]
