Prevent accidental update of a small set of libraries

Can we have an enhancement to Dependency Locking where only specified dependencies participate in locking?

Use case

I am developing a web application (not a library) with a large number of dependencies. With a large number of dependencies, it’s hard to avoid a situation where you update a patch version of an unimportant library and inadvertently cause a major update in a critical library, which causes problems such subtle that unfortunately your tests pass. Example from last week: markdown/ at master · JetBrains/markdown · GitHub.

I don’t want to go all-in into Dependency Locking. This is not a library. I don’t need to care about the smallest libraries. There is a limited set of libraries I want to watch (Guava, Kotlin, Spring). Maybe 10 of them at maximum. The build should fail if the version of any of those selected libraries goes up.

Existing solutions don’t work

I looked into Preventing accidental dependency upgrades but I don’t like any of solutions presented. I don’t think using failOnVersionConflict() makes any sense (I don’t care about transtitive deps with a lower version, those won’t update the resulting version).

Strict versions are not a solution either, because they silently downgrade dependencies and it’s extremely dangerous. Say I use strict Guava 27, then some library foo does a patch update that requires Guava 30. I end up with Guava 27, no warning whatsoever, and NoClassDefFoundError thrown by foo on production. Strict versions is a cure that is worse than disease.

I also tried using Rich Versions, like reject(1.2.3,). It seems to work as intended, but is a bit too imperative and verbose to use.

Locking dependency versions looks like what I need, but with an opposite approach. I would like to have an API like this to define what is included in the lock.

Usage · nebula-plugins/gradle-dependency-lock-plugin Wiki · GitHub has this style of API, with dependencyFilter taking a closure. But I don’t want this plugin. It’s practically unmaintained, does not work well with Kotlin, does not work at all with Configuration Cache.

This is more a community forum where users help users.

Assuming that you don’t want to just get some community feedback, but want this feature to be added, I’s like to suggest opening a feature request issue on GitHub instead. :slight_smile: