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

Gradle Community

feels like an odd thing to do, but `configuration2.resolutionStrategy.force("dep1:1.4.0")`?

Yep, declare the version as "strictly" <https://docs.gradle.org/current/userguide/rich_versions.html#header>
(note there's also a shortcut notation: `dep1:1.4.0!!`)

I guess both ways (via constraint and resolution strategy) are good but constraint will be surely exposed to consumers (if you publish something from configuration2) and forced resolution shouldn't be exposed iirc

Not about the technical solution, but depending on the use case, maybe it's clearer if you have a baseConfiguration, and dep20Configuration and dep14Configuration extend from it

&gt; feels like an odd thing to do
It is `compileOnly` configuration, so it is ok to have different versions of same dependency :slightly_smiling_face:

`resolutionStrategy.force(...)` doesn't work :man-shrugging:
Using rich versions causes the resolution excepion

this worked for me:
```val whatever by configurations.creating
whatever.extendsFrom(configurations.implementation.get())
whatever.resolutionStrategy.force("org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.3")
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.4")
}```

&gt; whatever
&gt; +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.10
&gt; |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.10
&gt; |    |    +--- org.jetbrains:annotations:13.0
&gt; |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.6.10
&gt; |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.10
&gt; |         \--- org.jetbrains.kotlin:kotlin-stdlib:1.6.10 (*)
&gt; \--- org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.4 -&gt; 0.3.3
&gt;      +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.30 -&gt; 1.6.10 (*)
&gt;      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.4.30 -&gt; 1.6.10
&gt; 
&gt; (*) - dependencies omitted (listed previously)


anyway I will probably go with your proposed way and will add separate configuration for this dependency that will be additionally added to compile classpath

to me it's clearer, I expect it to be used in 2 variants or just for tests, so it will show the intention better and having a named configuration it's a plus