janhoy opened a new pull request, #4794: URL: https://github.com/apache/solr/pull/4794
Our lockfiles carry ~470 entries for configurations named `runtimeClasspathCopy`, `compileClasspathCopy` etc. that nothing can ever refresh, so they go stale and pin old versions next to the real ones. On `main` today, `solr/core/gradle.lockfile` pins `slf4j-api` at both `2.0.17` and `2.0.18`. It broke a Lucene 10.5.1 upgrade attempt on dev@: every Lucene coordinate ended up locked at two versions at once. `collectJarInfos` calls `Configuration.copyRecursive()` to apply `jarValidation`'s exclude rules. Gradle names the clone `<source>Copy` and `lockAllConfigurations()` gives it lock state of its own — but the clone only exists while the task runs, so `resolveAndLockAll` never sees it, and Gradle's lockfile writer merges rather than rewrites, so the stale lines survive forever. # (Draft) Solution New `pinCopyToSource()` helper in `dependencies.gradle`: `deactivateDependencyLocking()` + `shouldResolveConsistentlyWith(source)`. The second half matters — dropping locking alone would let a transitive drift off the tested version and change which JAR gets license-checked. Applied in `jar-checks.gradle` and to the two same-shaped `copyRecursive()` sites in `packaging.gradle`. Then: stripped the dead entries (the writer can't do it), and dropped the now-pointless `collectJarInfos` from the lock command in `renovate.json` + docs, so all six places that document this finally agree on `./gradlew resolveAndLockAll --write-locks`. Build scripts, lockfiles and docs only — no production code. # Tests `validateJarChecksums`/`validateJarLicenses` pass with zero changes under `solr/licenses/`, i.e. the resolved JAR set is identical. Re-running the old bot command no longer reintroduces a single `Copy` entry. `resolveAndLockAll --write-locks` twice in a row is now an empty diff. A trial bump to Lucene 10.5.1 moves every coordinate cleanly. `./gradlew check -x test` passes. Unrelated and left alone: `solr/ui/gradle.lockfile` churns on every re-lock because `kotlinAbiValidationCompatClasspath` resolves an unpinned Kotlin version. Developed with assistance from Claude Code. -- 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]
