From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Isn't `force` deprecated anyway and you should use `strict` versions instead?

hm, I don't see any deprecation in api docs for `force`

Could you remind me how to set `strict` for all configurations in the project?

Ah, that was what I had in mind: <https://docs.gradle.org/current/userguide/upgrading_version_5.html#forced_dependencies>
&gt;  <https://docs.gradle.org/current/userguide/upgrading_version_5.html#forced_dependencies|Forced dependencies>
&gt; 
&gt; Forcing dependency versions using `force = true` on a first-level dependency has been deprecated.
&gt; 
&gt; Force has both a semantic and ordering issue which can be avoided by using a <https://docs.gradle.org/current/userguide/rich_versions.html#rich-version-constraints|strict version constraint>.
Not the `force` on the resolution strategy

The strict version is declared where you declare the version of the dependency, either by short-form, adding `!!` after the version, or by rich version declaration where you set the `strictly` property.

the problem - I need to force version also for detached configurations and some dynamically created ones (

Then you are lost.
You cannot influence detached configurations afaik, they are detached.
Even the `ResolutionStrategy#force` is something you do on a configuration and you do not get hold of detached configurations, because they are detached.

Usually you shouldn't care about detached configurations, they are just plugin internals that you should not influence and shouldn't care about.

btw `constraints { ... }` does not work in this case for non-detached configurations

Even if the constraint is with a strict version? o_O

yes - here is the <https://scans.gradle.com/s/5r3bkh6nmd6ho/dependencies?focusedDependency=WzAsNjksODM4LFswLDY5LFs4MzhdXV0&amp;toggled=W1swXSxbMCw2OV1d|build scan>. I am trying to force `1.8.10` version

Remove the `io.spring.dependency-management` plugin and use the built-in BOM support instead, even the maintainers of that plugin recommend that.

This plugin hooks into the resolution engine and overwrites the version on resolution which is why the strict version is overwritten

hm, could you point me to this?
&gt; even the maintainers of that plugin recommend that

Sure, have to search for the link, one moment

<https://www.linen.dev/s/gradle-community/t/2579116/What-is-the-proper-way-to-apply-a-BOM-in-a-library-project-i>

&gt; Andy Wilkinson: [...] In fact, it would have already happened if we'd had the bandwidth for it. I'd strongly encourage you to look at using Gradle's built-in platform support and find an alternative way of dealing with the lack of property-based version overrides.

The plugin is just a relict from the times when Gradle did not have built-in BOM support

+1 to not using spring dependencymanagement plugin anymore. it should be considered obsolete at this point imo

I actually have a convention plugin that deliberately fails when the spring dependencymanagement plugin is applied, as it shouldn’t be used.
```            prohibitPlugin(
                SPRING_DEPENDENCY_MANAGEMENT_PLUGIN_ID,
                "Spring dependency management plugin is not required"
            )

public fun Project.prohibitPlugin(pluginId: String, message: String) {
    withPlugin(pluginId) {
        error("Plugin prohibited: $pluginId; $message")
    }
}```