rangareddy commented on PR #857: URL: https://github.com/apache/incubator-xtable/pull/857#issuecomment-5213417918
Took the duplication point from #885 and applied it — `4c20169`. `license_overrides/` was a second committed copy of every curated text, and 1,405 of its 1,520 lines were byte-identical to a module's `META-INF/licenses/` copy. The generator now reads curated texts from the committed metadata, guided by a `CURATED_TEXTS` list naming the artifacts whose own jar has no usable license; everything else still comes from the jar, so an upgrade still picks up a changed text. Directory removed. Earlier in the same push, the CDDL text that was committed four times became one file. | | before | now | |---|---|---| | license files | 51 | **30** | | total lines | 9,050 | **5,253** | | duplicate lines | 6,369 | **2,623** | **3,746 duplicate lines removed.** PR is `+2845/-1718` across 39 files, from `+7356/-201` across 58. The 2,623 that remain are the shipped per-module copies — the `LICENSE-CDDL-1.1` convention change you flagged. Still leaving that alone until it's agreed. Verified: all 28 shipped texts regenerate byte-identical, so the jars are unchanged; the generator is idempotent; and deleting a curated text now fails the run naming the path to commit. Gates: rat pass, validator exit 0 (6 OK, no FAIL). A negative test caught one bug in the refactor — the failure path still referenced the removed directory and raised `NameError` instead of reporting — fixed before pushing. I did not swap the generator for #885's checker. Beyond the four defects in the earlier comment, it reads the coordinate listing from the jar it is validating, so it cannot see a dependency that is bundled but absent from that listing — I removed `javolution` from a jar's `META-INF/LICENSE` with its 305 classes still in place and the check stayed silent. Something still has to produce the listing correctly, which is what the generator does. I would rather add its jar-side check alongside, as a separate change, than trade one blind spot for another. One thing that surfaced while testing that integration, worth its own issue: the jar's own `META-INF/maven/*/*/pom.properties` shows artifacts arriving inside uber-jar dependencies — `avatica-1.11.0.jar` carries 12, `ehcache-3.3.1.jar` carries 3 — and their code is unattributed in `META-INF/LICENSE`. On a #880-built jar that is gson (173 classes), avatica (2,817), commons-codec (85), offheap-store (199), commons-logging (28) and others. Neither mechanism catches it today. It is not reachable from `main`, since `ehcache` and `avatica` are only bundled once #880 adds them — which is a further reason I am reworking #880 rather than raising it. -- 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]
