nick-boss-tech opened a new pull request, #5270: URL: https://github.com/apache/solr/pull/5270
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* ## Ready for review, but held as a draft due to the project's open-PR cap; I'll mark it open on request. Jira: [SOLR-17861](https://issues.apache.org/jira/browse/SOLR-17861) ## What happens today **The license checks do not cover the new Admin UI at all, and a checksum set generated on one operating system misses the other platforms.** The `updateLicenses` machinery keeps a committed checksum for every jar the project uses and validates the resolved dependencies against them. The Admin UI is a Kotlin Multiplatform module, so the machinery ignores it. Its desktop app also resolves different native libraries per operating system: Compose and Skiko publish a separate module for each of linux-x64, linux-arm64, macos-x64, macos-arm64 and windows-x64. Generating the checksums on any single OS covers only that OS's jars, and the ticket requires all platforms covered with an environment-independent check. ## What this change does **The desktop app's build enumerates one runtime classpath per platform and registers all five with the license tasks, so any host validates every platform.** - [`ui/desktopApp/build.gradle.kts`](https://github.com/nick-boss-tech/solr/blob/b0b0b39f7e62fa0247e133d4019bbb23f9def446/ui/desktopApp/build.gradle.kts) creates a detached runtime classpath for each desktop platform, extending the app's runtime classpath and selecting that platform's Compose and Skiko modules, and passes all five configurations to the license tasks. The app's own resolution is unchanged: it still resolves only the host OS. - 105 checksum files under `ui/licenses`, generated by `updateLicenses` from those five resolutions. ## Proof **Verified at `b0b0b39f7e` on Linux and on Windows 11: validation passes against the committed checksums on both.** <details> <summary>Verification at b0b0b39f7e</summary> - Linux, 2026-10-30: `:desktopApp:validateLicenses` passes at `b0b0b39f7e` against the committed files. - Windows 11 x64, 2026-10-27 (recorded on the Jira ticket): `validateLicenses` passed against the committed files before regeneration; `updateLicenses`, `validateLicenses`, `spotlessCheck` and `check` then all passed, producing the same 105 files. - The same generated set on two operating systems is the ticket's environment-independence criterion, demonstrated for the two OSes available to me. </details> ## A choice to check **Summary: the checksums exist for all five platforms because the build enumerates the five platform classpaths; whether that enumeration is the right mechanism is the open design question.** Context: on the ticket, @malliaridis doubted whether adding each OS's dependencies to the build is solving the problem the right way, and asked for this PR so the discussion can happen on the code. To weigh it: the build file above is the whole mechanism (one file plus the generated checksums); the per-OS modules are how Compose and Skiko publish (there is no single artifact with per-OS variants to resolve instead); and validation runs locally on any OS, which a CI-generated set would not allow. My recommendation: keep the enumeration. Any complete approach has to resolve all five module sets somewhere, because that is the shape of the upstream artifacts; doing it with detached configurations keeps the app's own resolution untouched and reuses the existing license tooling. Is enumerating the platforms in the build acceptable, or should the checksums be produced another way? ## Limits - No macOS host run: I have no access to a Mac, so the set is proven on Linux and Windows only; the macos checksums are generated from the same resolution, and a macOS run of `validateLicenses` would confirm them. - A future dependency that ships per-OS modules has to be enumerated for all five platforms when it is added, or its other platforms' jars stay uncovered. The enumeration is the maintenance rule this approach carries. - This covers checksums. Whether the UI's jars need LICENSE and NOTICE presence checks depends on whether the UI ships in the binary distribution, which is a separate packaging question. *AI-generated description. Nick Shanin directed the work and takes responsibility for this contribution.* -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
