rangareddy opened a new pull request, #19492:
URL: https://github.com/apache/hudi/pull/19492
### Describe the issue this Pull Request addresses
Partial fix for #19466 (follow-up from #19433). **Does not close it** — see
"What this PR does not do".
#19466 asks for three things: hoist the `maven-shade-plugin` POM flags into
the root shade
`<configuration>` and delete the 16 per-module copies; document why
`hudi-io` must keep
`createDependencyReducedPom=false`; and delete a dead relocation in
`hudi-aws-bundle`. This PR does the
second and third, plus one one-line item the issue lists in passing. All
three stand alone and are verified
here. The hoist is not included, for the reason given at the end.
### Summary and Changelog
**1. `packaging/hudi-aws-bundle`: delete the dead
`org.apache.httpcomponents.` relocation.**
```xml
<relocation>
<pattern>org.apache.httpcomponents.</pattern>
<shadedPattern>org.apache.hudi.aws.org.apache.httpcomponents.</shadedPattern>
</relocation>
```
`org.apache.httpcomponents` is the **groupId**, not a Java package — those
classes live under
`org.apache.http.*`. The rule matched nothing. They *are* relocated, by the
inherited root rule
`org.apache.http.` → `org.apache.hudi.org.apache.http.`, which applies
because
`<relocations combine.children="append">` merges the parent config.
**2. `hudi-io`: document why `createDependencyReducedPom=false` is correct
there.**
It is the only module in the repo using `shadedArtifactAttached=true` — the
shaded jar ships under the
`shaded` classifier while the main artifact stays unshaded, so its published
POM has to keep declaring
`protobuf-java`, which the primary jar genuinely needs. Reducing it would
strip a real dependency. The
comment states the invariant — **`false` is correct iff the shaded jar is
attached under a classifier** — so
it does not get "fixed" later by analogy with the packaging bundles.
**3. `packaging/hudi-timeline-server-bundle`: set
`dependencyReducedPomLocation`.**
The only bundle missing it, so it wrote `dependency-reduced-pom.xml` into
the module basedir instead of
`target/`. Confirmed: there was a stray one sitting there from an earlier
build. Only the location moves, so
the published POM content is unchanged by construction.
### Verification
**The dead relocation, built before and after:**
| | classes | `org/apache/http/` (unrelocated) |
`org/apache/hudi/org/apache/http/` | `org/apache/hudi/aws/org/` |
| --- | --- | --- | --- | --- |
| before | 16329 | 0 | 737 | **0** |
| after | 16329 | 0 | 737 | **0** |
The full class listing is diffed, not just counted, and is **identical**.
The zero in the last column is the
proof the rule was dead: had it ever matched, the classes would have landed
under
`org/apache/hudi/aws/org/apache/httpcomponents/`.
**The reduced POM location:** after deleting the stray file and rebuilding,
`packaging/hudi-timeline-server-bundle/dependency-reduced-pom.xml` is gone
and
`target/dependency-reduced-pom.xml` is written instead (7114 bytes); the jar
still has its 8454 classes.
**`hudi-io`** is a comment only.
### What this PR does not do
Hoisting `createDependencyReducedPom`, `promoteTransitiveDependencies` and
`dependencyReducedPomLocation`
into the root shade `<configuration>` and deleting the per-module copies —
the main body of #19466.
That is not a mechanical edit. For the seven bundles from #19433 the flags
already match what the root would
supply, so hoisting is a no-op for them. For the other nine it is not: they
currently get
`promoteTransitiveDependencies=false` by default, and hoisting would flip
it, **changing published POM
metadata for nine more artifacts**. The issue itself identifies the five
that carry real exposure
(`hudi-cli-bundle`, `hudi-kafka-connect-bundle`, `hudi-integ-test-bundle`,
`hudi-metaserver-server-bundle`,
`hudi-timeline-server-bundle`) and notes that the per-bundle
install-then-resolve verification "is the real
cost here, and is why #19433 deliberately stopped at seven".
I would rather land the three verified items than bundle them with nine
unverified published-POM changes —
that is exactly the risk #19433 avoided. The hoist deserves its own PR with
that verification actually
performed, and #19466 should stay open until then. Happy to pick it up next.
`hudi-examples-k8s`, which the issue also flags for a decision, is untouched
here for the same reason.
### Impact
No change to any jar's contents — proven by identical listings for
`hudi-aws-bundle`. No change to any
published POM's content. One stray file stops being written into a module
directory. The `hudi-io` change is
a comment.
### Risk Level
low — removal of a relocation rule proven to match nothing, one build-output
path, and one comment.
### 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
- [x] CI passes on my PR
--
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]
