Upgrading 32 dependencies on main branch#4305
Conversation
…g-runner to v2.8.4
…figurations Local resolveAndLockAll could not resolve wasmJs configurations and left kotlinx-coroutines-bom/swing/test/test-wasm-js at 1.10.1 for those configs. Apply the correct 1.10.2 versions from PR apache#3313 so all configurations consistently use the new version, fixing the CI 'strictly 1.10.1' lock conflict.
dropwizard-metrics 4.2.34+ requires Jetty 12.1.x, which is incompatible with Solr's embedded Jetty 12.0.x. Downgrade to 4.2.33 (last version supporting Jetty 12.0.x) and upgrade eclipse-jetty from 12.0.27 to 12.0.34. jersey-container-jetty-http:4.0.2 is compatible with Jetty 12.0.x. Regenerate lockfiles and update license checksums for new Jetty version.
dropwizard-metrics 4.2.34+ requires Jetty 12.1.x, which is incompatible with Solr's embedded Jetty 12.0.x. Downgrade to 4.2.33 (last version supporting Jetty 12.0.x) and upgrade eclipse-jetty from 12.0.27 to 12.0.34. jersey-container-jetty-http:4.0.2 is compatible with Jetty 12.0.x. Regenerate lockfiles and update license checksums for new Jetty version.
BC 1.84 added several new Security.getProperty() calls for internal configuration properties (ec.max_f2m_field_size, asn1.max_cons_depth, etc.) that were blocked by the test security manager. Add all property permissions found in the BC 1.84 jar to avoid future one-by-one failures.
BC 1.84 added two new Security.getProperty() lookups that are denied by the test and server security managers. Discovered by running JWTAuthPluginIntegrationTest in a loop until all denials surfaced: - org.bouncycastle.ec.max_f2m_field_size (EC F2m field size limit) - org.bouncycastle.asn1.max_cons_depth (ASN.1 constructed depth limit) Added to both solr-tests.policy and server/etc/security.policy.
|
I ran the entire test suite locally and after updating security policy for BouncyCastle upgrade, it all pass. So I'll take this out of draft mode and ready for review, first by Copilot... |
|
I like this innovative approach to dealing with dependencies... It has felt to me like more and more time has been going into dependency management and that it was a Sisyphean task. On other projects that are smaller like Quepid I basically do a two day spasm of updating dependencies, manually test, and then call it good about three times a year ;-). I don't have the intertwined issues that we get in Solr! I wonder if dependency upgrades really need to be in our changelog? If our changelog is for end users, unless a dependency is fixing some big exciting thing, or it's a big new feature, I suspect it's just noise. |
You will see for most changelogs out there, dep upgrades will be a major part of the changelog, and I believe it makes sense. Perhaps more so for libraries such as Solrj. For Solr server it will alert users about whether they can expect a certain bug/cve to be fixed in a given version, which they otherwise would have to scan source code or git to find out. Speaking about SolrJ, since we don't publish it as a separate artifact (should we?), it would perhaps be useful to have a separate changelog section for solrj dependency upgrades. Eh, well folks can see dependencies in maven central too, I don't know.. |
This is the happy-path. Dealing with low hanging fruits. After merging this, there will still be plenty of dep upgrades that did not pass checks, that need manual tweaks, added LICENSE files etc. My thinking is that volunteer can work on each individual problematic solrbot PR to figure out each of them, with or without AI help, and once the PR branch is green, merge it, or gather a bunch of such into a common branch like her. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 300 out of 346 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| org.junit.jupiter:junit-jupiter-api:5.6.2=jarValidation,testCompileClasspath,testRuntimeClasspath | ||
| org.junit.platform:junit-platform-commons:1.6.2=jarValidation,testCompileClasspath,testRuntimeClasspath | ||
| org.junit:junit-bom:5.13.4=compileOnlyHelper,compileOnlyHelperTest | ||
| org.junit:junit-bom:5.14.0=compileOnlyHelper,compileOnlyHelperTest | ||
| org.junit:junit-bom:5.6.2=jarValidation,testCompileClasspath,testRuntimeClasspath |
There was a problem hiding this comment.
The version catalog updates JUnit Jupiter to v6.0.3, but this lockfile still pins JUnit Jupiter/BOM to 5.6.2-era artifacts. With dependency locking enabled, this mismatch is likely to break dependency resolution (or prevent the intended upgrade). Regenerate/write lockfiles after updating versions (e.g., --write-locks) so the locked JUnit coordinates match the requested versions, and ensure only the intended JUnit BOM/Jupiter versions are locked for the relevant configurations.
| authors: | ||
| - name: Jan Høydahl | ||
| links: | ||
| - name: PR#4093 |
There was a problem hiding this comment.
The changelog link text and URL refer to different PR numbers (PR#4093 vs /pull/4305). Update either the name or the url so they match the actual PR for this change.
| - name: PR#4093 | |
| - name: PR#4305 |
| @@ -0,0 +1,7 @@ | |||
| title: Update org.eclipse.jgit:org.eclipse.jgit to v7.5.0.202512021534-r | |||
There was a problem hiding this comment.
This changelog entry says JGit was updated to v7.5.0.202512021534-r, but gradle/libs.versions.toml in this PR sets eclipse-jgit to 7.6.0.202603022253-r. To avoid a misleading release note, update the changelog title to the effective version being shipped (or adjust the version catalog if the changelog is correct).
| title: Update org.eclipse.jgit:org.eclipse.jgit to v7.5.0.202512021534-r | |
| title: Update org.eclipse.jgit:org.eclipse.jgit to v7.6.0.202603022253-r |
| @@ -0,0 +1,7 @@ | |||
| title: Update mockito to v5.21.0 | |||
There was a problem hiding this comment.
The version catalog/lockfiles in this PR upgrade Mockito to 5.23.0, but this changelog entry still states v5.21.0. Update the changelog entry to reflect the actual version included by this PR.
| title: Update mockito to v5.21.0 | |
| title: Update mockito to v5.23.0 |
| @@ -0,0 +1,7 @@ | |||
| title: Update org.checkerframework:checker-qual to v3.53.1 | |||
There was a problem hiding this comment.
This changelog entry states checker-qual v3.53.1, but this PR adds solr/licenses/checker-qual-3.54.0.jar.sha1 and sets checkerframework = \"3.54.0\" in the version catalog. Update the changelog title to match the effective version being shipped.
| title: Update org.checkerframework:checker-qual to v3.53.1 | |
| title: Update org.checkerframework:checker-qual to v3.54.0 |
| nodegradle-node = "7.1.0" | ||
| # @keep Node JS version used in node.gradle (LTS) | ||
| nodejs = "22.18.0" | ||
| onnx = "1.23.0" |
There was a problem hiding this comment.
This PR updates the locked/test dependency com.microsoft.onnxruntime to 1.24.3 (and adds the corresponding solr/licenses/onnxruntime-1.24.3.jar.sha1), but the version catalog still lists onnx = \"1.23.0\". Align the catalog with the effective ONNX Runtime version to avoid future lockfile churn or accidental downgrades.
| onnx = "1.23.0" | |
| onnx = "1.24.3" |
Bulk dependency upgrade for main branch. Asked Claude to merge all "clean" solrbot PRs for main into this feature branch. There will be another batch of "clean" upgrades later.
This PR also "manually" upgrades Jetty to 12.0.34 (latest 12.0.x version as 12.1 is breaking chage), and dropwizard-metrics to 4.2.33 (since later will require Jetty 12.1). The solrbot PR branches merged into this are the following: