SpringBoot Gradle plugin ignores dependency constraints

dependency constraints is the preferred method to express constraints that should be applied to all dependencies

here is a repo to replicate https://github.com/rfigueroa/dependencies-constraints When using spring-boot 2.4.6 with the okta starter a dependency on json-smart.2.3.1 is pulled by the okta starter; a constraint is added to upgrade the transitive dependency from 2.3.1 to 2.4.7

constraints {
        implementation('net.minidev:json-smart:2.4.7') {
            because 'version 2.3.1 has a bug impacting this application'
        }
}

to replicate run

 ./gradlew assemble
 cd build/libs
 java -Djarmode=layertools -jar dependencies-constraints-0.0.1-SNAPSHOT.jar extract
 cd dependencies/BOOT-INF/lib

and see that the constraint to upgrade json-smart to 2.4.7 was ignored and the app still has 2.3.1 as a dependency

a workaround is to add 2.4.7 as a direct dependency

implementation("net.minidev:json-smart:2.4.7") {
     because("dependency constraint is ignored")
  }

but it would be better if the expected behavior that gradle recommends is respected

Comment From: wilkinsona

This is due to your project's use of the dependency management plugin which uses a resolution strategy to enforce versions. This trumps any dependency constraints that have been configured.

When using the dependency management plugin, versions from Spring Boot's dependencies bom should be overridden using the documented version properties. In this case the property would be json-smart.version:

ext['json-smart.version'] = '2.4.7'

Alternatively, if you prefer a more Gradle-native approach, you can use Spring Boot's dependencies bom as a platform or enforced platform. You can then override versions from the Platform using any native Gradle mechanism. Note that the more concise property-based version overrides offered by the dependency management plugin will no longer work.

A future version of the dependency management plugin may move away from using a resolution strategy to configuring constraints that could then potentially be overridden with other constraints. That would have to be done as part of raising the minimum version of Gradle support by the dependency management plugin as constraints are not available in all versions of Gradle that the plugin currently supports.

Comment From: rfigueroa

thank you for the quick response, This trumps any dependency constraints that have been configured. this bit made everything click, the links to the docs are 👨🏼‍🍳