Bump dependencies to current stable versions - #1787
Conversation
Routine dependency refresh. All bumps are patch/minor within the same major
version, so no source changes are required; the full test suite (22,092 tests)
passes and a -Xlint:deprecation,removal compile surfaces no new deprecations
and no removal-track usages introduced by the bumps.
Runtime/implementation:
snappy-java 1.1.10.5 -> 1.1.10.7
commons-compress 1.26.0 -> 1.28.0
xz 1.9 -> 1.10
org.json 20231013 -> 20250517
commons-logging 1.3.0 -> 1.3.6 (transitive-pin constraint)
Test-only:
testng 7.8.0 -> 7.11.0
guava 33.0.0-jre -> 33.4.8-jre
commons-lang3 3.14.0 -> 3.20.0
Left unchanged deliberately:
commons-jexl 2.1.1 - only upgrade path is jexl 3.x, a major API rewrite
(different package/engine API, and the source of the old commons-logging
pull). That is a migration, not a bump; tracked separately.
nashorn-core 15.7, jlibdeflate 0.1.0, jimfs 1.3.0 - already latest.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughUpdated runtime, transitive, and test dependency versions in ChangesGradle Dependency Updates
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@build.gradle`:
- Line 47: Update the dependency versions in build.gradle for snappy-java, xz,
org.json, commons-logging, testng, and guava to their newer stable releases,
while leaving commons-compress and commons-lang3 unchanged. Alternatively,
narrow the PR to explicitly pin only the intended versions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
An earlier version query (search.maven.org solr) returned stale "latest" values; the authoritative maven-metadata.xml shows newer stable releases for six of the bumped artifacts. Correcting to the actual latest: snappy-java 1.1.10.7 -> 1.1.10.8 xz 1.10 -> 1.12 org.json 20250517 -> 20260522 commons-logging 1.3.6 -> 1.4.0 testng 7.11.0 -> 7.12.0 guava 33.4.8-jre -> 33.6.0-jre commons-compress (1.28.0) and commons-lang3 (3.20.0) were already current. Full suite (22,092 tests) still passes; no new deprecation/removal warnings.
|
Good catch — you were right. My original version query used the search.maven.org solr index, which returned stale |
Routine dependency refresh — bumps every direct library dependency that had a newer patch/minor release to its current stable version. All bumps stay within the same major version, so no source changes were needed.
Bumps
Runtime / implementation:
org.xerial.snappy:snappy-javaorg.apache.commons:commons-compressorg.tukaani:xzorg.json:jsoncommons-logging:commons-logging(transitive-pin constraint)Test-only:
org.testng:testngcom.google.guava:guavaorg.apache.commons:commons-lang3Left unchanged (deliberately)
commons-jexl2.1.1 — the only upgrade path is jexl 3.x, a major API rewrite (different package +JexlEngine/expression API, and the source of the legacy commons-logging pull). That's a migration, not a bump; tracking it separately.nashorn-core15.7,jlibdeflate0.1.0,jimfs1.3.0 — already at the latest published version.Verification
-Xlint:deprecation,removalcompile: the bumps introduce no new deprecation warnings and no removal-track API usages.Gradle plugin upgrades (shadow, spotbugs, spotless) and a possible Gradle wrapper bump are intentionally out of scope here — they change the build itself and will get their own PR.
Summary by CodeRabbit