This message was deleted.

On the build scan you can select a given dependency (one of the 1.7.22 ones) and see who requested that dependency version.

Thanks. I couldn't find any further information about the source in the scan. But I finally narrowed it down to the Spring Boot BOM, which was depending on Kotlin 1.7.22. Though even after discovering this, I wasn't able to discover this link using Gradle or the build scan

Don't use the spring dependency management plugin, but the built-in BOM support. That plugin is a relict from times when Gradle did not have that and even its maintainer is recommending but to use it anymore

Thanks a lot for the info! Removing the dependency management plugin does indeed seem to make dependency management simpler, and the build quicker… 🤯 Do you have any pointers to where use of that plugin is being discouraged?

Using the dependency-management plugin means you give it the keys to managing your dependencies, so don't expect to understand what actually happens without also knowing how to use the plugin; you're no longer "just" using Gradle's dependency resolution. This is (kind-of) explicitly mentioned in their documentation (https://docs.spring.io/spring-boot/docs/3.1.2/gradle-plugin/reference/htmlsingle/#managing-dependencies, https://docs.spring.io/dependency-management-plugin/docs/1.1.2/reference/html/). This also means that whatever you're finding online about dependency management in Gradle doesn't really apply; it's no longer a "Gradle project" as far as dependency management is concerned, it's a "Spring project". If you're comfortable with Gradle's dependency management, then don't use it and manage dependencies "manually": https://docs.spring.io/spring-boot/docs/3.1.2/gradle-plugin/reference/htmlsingle/#managing-dependencies.gradle-bom-support; then you're using only Gradle for dependency management, and can use everything it provides to understand and manage your dependency resolution. This is the reason people in this Slack discourage using the plugin.

Thanks for the extra context. Yeah, I did end up using

kotlin.version

to fix things (it turned out we were already using that mechanism to fix our jOOQ dependency as well). But after the recommendation here, I tried removing the plugin, but kept the Spring Boot BOM. With that, the Kotlin troubles disappeared, and dependencies were no longer being overridden in such a non-obvious way. So I'm happy to have a more "normal" Gradle build, without the plugin 👍

This is the reason people in this Slack discourage using the plugin.

No. The reason why people recommend not to use the plugin is, because it is an obsolete relict from a time when Gradle did not have built-in BOM support. The reason why people recommend not to use the plugin is, because it adds no value and just makes things harder to understand and manage. The reason why people recommend not to use the plugin is, because even the maintainer of the plugin recommends not to use the plugin but to use the built-in functionality instead. (https://linen.dev/s/gradle-community/t/2579116/what-is-the-proper-way-to-apply-a-bom-in-a-library-project-i#a7d4a60a-ab60-48dc-8477-f3f4462d1e6a)

Do you have any pointers to where use of that plugin is being discouraged?

Sure: always and everywhere, unless you use an ancient Gradle version that does not yet have BOM support built-in.

Thanks for the link!