Hey folks - platform/version constraint question f...
# community-support
a
Hey folks - platform/version constraint question for you all here today 🙂 We've got a couple of instances where slf4j-api 2.x is coming in as a transitive dependency and I'd like to force the resolution of it to 1.7.X. Right now we're on 1.7.36 mostly, but anything 1.8+ we don't want. We have an internal platform we made where I'm trying to specify the constraint, but I'd like it to resolve to 1.7.36. but I'm getting failures complaining about 2.0.6/2.0.9 even if the version catalog entry in my platform is this: slf4j-api = "[1,7, 1,8[" I suspect my rule is a bit too strict maybe? I'd like this scenario: 2.0.6/2.0.9 is not rejected, but the platform will downgrade them into 1.7.X...which will currently be 1.7.36 but can update into newer versions of 1.7.X if they are available on the classpath thanks in advance :)
t
Try with
"1.7.36!!"
or
{ strictly = "[1.7, 1.8[", prefer = "1.7.36" }
https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:strict-version-consequences That being said, beware of such downgrades as you could have failures at runtime if those libs use slf4j's fluent api; I'd rather investigate upgrading to an slf4j-2-compatible logging library (slf4j 2 has been stable for more than a year and a half already)
✅ 1
a
yeah I agree with you, but I am fighting a one-man battle on this in my org so regrettably the downgrade has to be the current approach. Thanks Thomas!