DanielLeens commented on PR #11648:
URL: https://github.com/apache/seatunnel/pull/11648#issuecomment-5350159602
@loustler — good catch, and I don't think this should sit unanswered while
you wait on @hawk9821/@davidzollo, since I can at least verify the source-level
facts you're reasoning from (the governance call on splitting/sequencing is
genuinely theirs to make, not mine).
I re-checked `dev` independently rather than taking either your read or
#11851's stated rationale on faith:
- Root `pom.xml:56` — `<module>seatunnel-shade</module>` is still present.
- `seatunnel-shade/pom.xml` still declares all 14 of its own sub-modules,
including `seatunnel-hadoop3-3.1.4-uber` and `seatunnel-hadoop-aws` — nothing
has been stubbed out or emptied there.
- `seatunnel-dist/pom.xml` resolves both of those artifacts at
`${project.version}` in four places (lines 963-965, 994-996, 1243-1245,
1272-1274) — i.e. from the reactor's own SNAPSHOT build, not a pinned Central
coordinate like `3.1.4-3.0.0`.
So your reading matches what's actually on `dev` right now: a full `mvn
install` from root today still builds `seatunnel-shade` locally and
`seatunnel-dist` still consumes exactly that local build. That's in tension
with #11851's stated premise ("modifications to the shade module made within
this repo... are no longer effective") — as of this exact commit on `dev`, an
in-repo shade change *would* still flow into the packaged jar. I can't tell
from source alone whether that's because #9993 (still open) is the actual
cutover point and #11851 got ahead of it, or whether there's a release/CI-side
decision already made off-list that source inspection won't show me — that
distinction is for @hawk9821/@davidzollo to settle, not something I can infer.
What I can say with confidence on the file-count question: your 3-vs-85
split is exactly right by my own accounting too — I reviewed
`seatunnel-shade/pom.xml`, `seatunnel-shade/seatunnel-hadoop-aws/pom.xml`, and
the `seatunnel-hadoop3-3.1.4-uber` → `seatunnel-hadoop3-3.4.3-uber` rename as
the only shade-tree files across all six of my prior rounds, and the artifact
rename is the one piece I flagged as needing the `incompatible-changes.md`
entry specifically because it's an artifactId change rather than the
version-in-artifact-version scheme `seatunnel-shade` uses upstream. If the
split you're proposing goes ahead, that's worth carrying over as context for
whoever reviews the shade-repo PR: the SDK v2 bundle-filtering config in
`seatunnel-hadoop-aws/pom.xml` is what keeps that jar in the ~25MB range, so it
isn't optional plumbing.
I'd rather not guess at your questions 1 and 3 (whether sources here are
already considered frozen, and shade-release turnaround time) since those are
project-management calls I have no privileged information on beyond what's in
the two PRs above. But if it helps unblock a decision: nothing about the
current `dev` state forces you to stop work today on technical grounds — the
shade changes in this PR would still take effect in a build as things stand —
the only open question is which direction the maintainers intend to lock in
before #11648 merges.
--
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]
