Bump slf4j and logback to match Terasology - #176
Conversation
slf4j-api 1.7.25 -> 2.0.18, logback-classic 1.2.3 -> 1.6.0 in the version catalog, matching Terasology's pins. gestalt-android and gestalt-android-testbed pin slf4j-api strictly to 1.7.25: logback-android (1.3.0-3, the latest release supporting our minSdk 24) predates SLF4J 2.x's provider mechanism, so pairing it with slf4j-api 2.x would silently no-op all logging on Android rather than fail the build.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughSummary by CodeRabbit
WalkthroughThe PR updates SLF4J and Logback versions in the version catalog and Gradle lockfiles. The Android module and testbed override the catalog with a strict SLF4J API version of 1.7.25. ChangesDependency alignment
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The dependency updates preserve Android compatibility through the documented SLF4J pin and logback rationale. No actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. (10 skipped: 10 unsupported.) ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Bumps
slf4j-apiandlogback-classicto match Terasology's pins:slf4j-api: 1.7.25 -> 2.0.18logback-classic: 1.2.3 -> 1.6.0gestalt-androidandgestalt-android-testbedpinslf4j-apistrictly back to 1.7.25.logback-android:1.3.0-3(the latest release compatible with ourminSdkVersion 24- the next release, 3.0.0, requires API 26 and is the only one that supports SLF4J 2.x) predates SLF4J 2.x's provider-discovery mechanism. Pairing it withslf4j-api2.x wouldn't fail the build, but would silently no-op all logging at runtime (SLF4J 2.x can't find a compatible provider and falls back to NOP with a one-time warning).Verified locally against a real Android SDK (compileSdk 36, AGP 9.3.1):
gestalt-android:assembleDebugandgestalt-android-testbed:testDebugUnitTestboth pass, withslf4j-apiconfirmed resolving to1.7.25on the Android runtime classpath viadependencyInsight.testsuite: only the 3 known pre-existing failures (SandboxTest/PermissiveSandboxTest/EmbeddedLibraryTest, blocked bySecurityManagerremoval on newer JDKs, and the flakyModuleEnvironmentWatcherTest), all reproduced identically against a clean, unmodifieddevelopcheckout.Lockfiles regenerated for every affected module.