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
Task Description
What needs to be done:
Add
hudi-presto-bundlecoverage topackaging/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-bundlesilently shipped a jar containing 0org/apache/hudi/hadoop/**entries instead of 109, losingHoodieParquetInputFormat-- the class the bundle exists to provide. Shade does not fail when anartifactSetinclude 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-validationreturns nothing, and the same is true fortrino.validate.shexerciseshudi-cli-bundle,hudi-kafka-connect-bundle,hudi-metaserver-server-bundle,hudi-utilities-bundleand the spark/flink bundles. Of the seven bundles touched by #19433, onlyhudi-hadoop-mr-bundleappears inbundle-validationat all --hudi-presto-bundle,hudi-aws-bundle,hudi-gcp-bundle,hudi-datahub-sync-bundleandhudi-hive-sync-bundlehave no stage. (Theazurematches under that directory are the Azure Pipelines config, nothudi-azure-bundle.)2. Even with a stage,
-amwould hide this class of bug. Every-pl packaging/...invocation under.github/workflowsandscripts/passes-am-- 10 out of 10 on master. With-amthe dependency bundles are built in-reactor, and Maven'sReactorReaderserves 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~/.m2masks it the same way.Suggested minimum: a validation step asserting the presto bundle contains
org/apache/hudi/hadoop/HoodieParquetInputFormat.class, built without-amsohudi-hadoop-mr-bundleresolves 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
artifactSetinclude 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