Apply dependency management as constraints

[wilkinsona]

Move away from using a resolution strategy to applying dependency management as constraints. Each constraints can use because to describe why it's in place, for example managed by org.springframework.boot:spring-boot-dependencies:2.7.1. Like Gradle's platform support, the constraints should indicate a required version (a minimum acceptable version). We should also offer support for constraints with strict versions as Gradle does with an enforced platform.

[igormukhin]

Just bumped into that issue.

Wanted to set a constraint on a transitive dependency that is managed by Spring Boot, but the plugin overrides my constraints.

The constraint:

dependencies {
    //...

    constraints {
        implementation("net.minidev:json-smart").version { require("2.5.2") }
    }
}

The override:

...
|    \--- io.micrometer:micrometer-observation:1.14.2 (*)
+--- com.jayway.jsonpath:json-path -> 2.9.0
\--- net.minidev:json-smart:2.5.2 -> 2.5.1 (c)

[jordanjennings]

Is there any way today to specify a minimum acceptable version of a dependency, but let the dependency management plugin use a newer version if the spring dependencies call for it? The use case is for security vulnerabilities, sometimes you need version 1.2.10 of a library or greater, but spring uses 1.2.5 and if I set the version to 1.2.10 then I lose out on future upgrades that come along with Spring upgrades.

Ideally this would work with native gradle dependency constraints, which I think is what this ticket is about, but I'm hoping there's some way to do it today even if with some less ideal syntax.