question for people using dependency locking: since it leads to a build failure if there are any changes in the resolved dependencies of a build, what kind of pushback have you had from non-build engineers? Are they frustrated by this additional friction? how have you minimized that, assuming you've tried to do so? any lessons learned?

not using dependency locking on any current projects, but created and maintained something equivalent previously (before Gradle's native dependency locking). other engineers were not happy but pushback was obviated by "our legal department interprets PCI compliance to require this"

That's why I created dependency guard. Need to share publicly, but happy to do a private demo.

@Sam Edwards interesting. I wonder what would make your situation different from mine? Because I tried changing a dependency and got a build failure when running `:dependencies`:

* What went wrong:
A problem occurred configuring root project 'register'.
> Could not resolve all files for configuration ':classpath'.
   > Resolved 'com.google.protobuf:protobuf-javalite:3.18.1' which is not part of the dependency lock state

this was for the build classpath

In mine, you can change any dependencies you want. But if you run

./gradlew dependencyGuard

then it'll compare to the baseline and fail with the difference. Then you can rebase with

./gradlew dependencyGuardBaseline

. You can do a dependsOn() if you want to commonly run the

dependencyGuard

task to find the change early, but otherwise you can have CI fail the build with it. It just forces "intentional dependency changes". The big part of it is catching transitive dependencies for a specific config.

I tried dependency locking when it created many files, it was terrible. Once it's just one file a team tried (and I think they are using it) but the last thing I know is that it was frustrating all the time because if failed when it shouldn't... Mostly it seems an issue of having too many configurations (Android project + typical static analysis tools). The only reason they wanted to use it is to detect transitive dependencies changing. With dependency locking they can see the change in the PR.

I'm wondering if what I want is dependency verification. But really, neither appears to be quite intended for my use-case, which is simply to see when a version changes or when a new (usually transitive) dependency appears. They both can do that, but that does not seem to be the intended purpose. Dependency verification is probably worth doing anyway, for security reasons, but...

I think your usecase is the same I was speaking of. "I want to notice changes in transitive dependencies so my app doesn't unexpectedly in runtime later"

👀

If your need is only to detect transitive dependency changes in PRs, then have a look at https://github.com/JakeWharton/dependency-tree-diff

It's not good you have the same problem as me, but you do!