zmuxuny commented on issue #5085: URL: https://github.com/apache/rocketmq-dashboard/issues/5085#issuecomment-5934608075
Rechecked against `rocketmq-studio@a460673f`: the [upstream backend build](https://github.com/apache/rocketmq-dashboard/actions/runs/36849906283/job/110328993085) still reports **164 missing complete dependency LICENSE/COPYING materials**, plus the Spring Boot loader's missing original `META-INF/LICENSE.txt` / `NOTICE.txt`. Compilation and Boot repackaging finish before this gate fails. The same diagnostics recur in the [current PR build](https://github.com/apache/rocketmq-dashboard/actions/runs/36882733561/job/110438316458). The relevant contract is explicit: [`collect_jar`](https://github.com/apache/rocketmq-dashboard/blob/a460673fb5b1c61b06f06bac5e48428bb479fa07/server/scripts/legal.py#L108-L140) reads materials only from the embedded JARs, while `add_component` requires a sufficiently long LICENSE/COPYING file. There is currently no source-backed fallback for an artifact that omits those files. One implementation direction for discussion, preserving the gate: 1. Generate an inventory from the actual fat JAR, recording each dependency's coordinates/version, artifact checksum, embedded materials, and missing requirements. The 164 diagnostics need not imply 164 unrelated license sources. 2. Add an explicitly reviewed fallback-material manifest for the missing entries, pinned to exact artifact identity/checksum and upstream source revision/URL, with checksums for the original license, copyright, and applicable notice files. Preserve already embedded materials rather than replacing them with generic license names. 3. Handle the Boot loader separately using the original materials for the exact Boot version. 4. Keep unknown artifacts, changed checksums, missing materials, and unresolved manual-review findings as failures. This would not equate collected texts with approval of redistribution rights. Regression coverage should include a missing fallback, a valid fallback retained in the final JAR, checksum/version drift, preserved NOTICE content, and post-packaging tampering. Acceptance should include the real dependency set, not only the existing one-component fixture. Would this conservative fallback approach fit the intended packaging contract? Agreement on that boundary would help before sourcing a large set of materials or changing the script's behavior. This is a proposal, not a claim that the licensing review or packaging fix is complete. The frontend artifact-hash work in #5019 / #5083 is a separate gate. -- 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]
