voonhous commented on code in PR #19433:
URL: https://github.com/apache/hudi/pull/19433#discussion_r3701741478
##########
packaging/hudi-aws-bundle/pom.xml:
##########
@@ -117,7 +117,7 @@
<shadedPattern>org.apache.hudi.aws.org.apache.httpcomponents.</shadedPattern>
Review Comment:
Answering the open question here: neither. I folded it into #19466 rather
than filing it on its own or cleaning it up in this PR.
That issue hoists `createDependencyReducedPom`,
`promoteTransitiveDependencies` and `dependencyReducedPomLocation` into the
shared shade config in the root pom, which means editing all 16 `packaging/*`
POMs anyway -- so deleting four dead lines in one of them rides along at no
extra risk, and it is too small to be worth its own issue. The evidence from
this thread is written into it, including that the relocation that actually
applies is the inherited root rule.
Nothing further needed in this PR.
##########
packaging/hudi-hadoop-mr-bundle/pom.xml:
##########
@@ -136,7 +136,7 @@
<shadedPattern>org.apache.hudi.com.fasterxml.jackson.</shadedPattern>
</relocation>
</relocations>
- <createDependencyReducedPom>false</createDependencyReducedPom>
+ <createDependencyReducedPom>true</createDependencyReducedPom>
Review Comment:
Yes, wanted. Filed as #19468 and assigned to you -- reassign freely if you
would rather not carry it.
I verified both halves of your CI observation before writing them into the
issue, and both hold exactly as you stated: **10 out of 10** `-pl
packaging/...` invocations under `.github/workflows` and `scripts/` pass `-am`,
and `packaging/bundle-validation` has **zero** matches for `presto` or `trino`.
Worth noting they are independently sufficient -- even with a presto stage
added, `-am` builds the dependency in-reactor and `ReactorReader` serves the
effective model, so the resolution path that actually broke still would not be
exercised. The issue asks for the stage to run without `-am` for that reason.
One thing I added beyond the presto stage: a check that fails the build when
a shade `artifactSet` include matches no artifact. That is the actual root
cause of the silent 109 -> 0 shrinkage, and it would cover all 16 bundles
instead of hardening one bundle at a time.
--
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]
