vinishjail97 commented on PR #857: URL: https://github.com/apache/incubator-xtable/pull/857#issuecomment-5209106233
Stepping back on scope, with numbers taken from the built artifacts rather than the poms. I built both branches and compared each bundled jar's `META-INF/LICENSE` against the classes actually inside it, matching every documented coordinate against that artifact's own jar in `~/.m2`. The remaining gap for #700 is smaller than this PR assumes: **main** — 10 non-Apache-2.0 dependencies shipped with no license text - `xtable-aws`: `zstd-jni` (BSD 2-Clause), `reactive-streams` (MIT) - `xtable-hive-metastore`: `aopalliance`, `zstd-jni`, `junit:4.11`, `org.antlr:ST4`, `hamcrest-core`, `stax-api`, `xml-apis`, `xmlenc` - `xtable-hudi-support-extensions`: none **branch-0.4** — 17: the same two in `xtable-aws`, 14 in `xtable-hive-metastore`, and `checker-qual` in `xtable-spark-runtime`, which ships no `META-INF/licenses/` directory at all. The coordinate listings are in reasonable shape. It is only the texts that were never produced, and the validator on `main` makes no assertion about `META-INF/licenses` at all (`grep -c 'META-INF/licenses' ` returns 0) — which is why this stayed invisible even before the ripgrep fail-open you found. Given that, would you consider narrowing this PR to: 1. commit those texts, and 2. validate against the built `*-bundled.jar` instead of the dependency tree — read the non-Apache-2.0 coordinates from the jar's own `META-INF/LICENSE`, fail on a missing text, and fail on a text with no bundled dependency behind it. Checking the artifact rather than the tree removes the need for POM family resolution, the override tables, the parse fallbacks and the `<includes>` intersection, and with them the dependency on #880 — the check no longer cares what the includes list claims. It also closes #865 in the same pass, and it covers `xtable-spark-runtime` on branch-0.4, which the current metadata does not. I prototyped the check locally at about 45 lines and it reproduces the numbers above on both branches. Happy to push it as a branch if that is useful. For what it's worth, a good part of the size here came from my earlier review asking for more hardening inside the generator. That was the wrong question to lead with, and I am sorry for the churn — the POM-parsing work you did is genuinely careful, it just may not need to exist. -- 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]
