Faced a problem with dependency locking mechanism:
Project is a multimodule android app where only app module is locked.
I expected that build will fail on simple, manual update of a regular(non dynamic) version until i rewrite locks. But it didn't.
For example i upgraded some version of my 3rd party dependency, let's call it com.dep:dep
: from 1.0
to 1.2
and build finished correctly
even with this particular dependency locked on 1.0 in app's gradle.lockfile
Asked in gradle community slack, but failed to describe my issue correctly (at least should mention multimodule app/): https://gradle-community.slack.com/archives/CAH4ZP3GX/p1632215556061900
Thanks to Louis Jacomet, i understood that at least my expectations are correct.
So what was the problem?
app
with gradle.lockfile locked with (com.dep:dep:1.0
),app
doesn't have direct dependency oncom.dep:dep
app
depends onlib
withimplementation
lib
has direct dependency oncom.dep:dep.1.0
lib
doesn't have locking enabled
I tried to update com.dep:dep:1.0
-> 1.2
Expect it to fail on app
dependencies resolving.
It didn't. Why?
lib
successfully resolvedcom.dep:dep:1.2
app
resolved transitivecom.dep:dep
and1.0
wins because it's a locked version!
making 1.2
"strictly" will fail the build because two different constraints: from lockfile and libs
couldn't be resolved.
So how you should lock versions in multimodule project to fullfil this expectations?
I decided to lock all modules; this way build will fail on libs
resoving.
Probably it somehow should be reflected in docs?