This message was deleted.

I have a solution, which is to make a new configuration just for running tasks, taskRuntimeClasspath, and then have things use sourceSets.main + configurations.taskRuntimeClasspath, is this appropriate?

I ran into the same when migrating from spring dep mgmt to using platforms. I felt there was a gap in the documentation related to this, so I opened a ticket to enhance it. https://github.com/gradle/gradle/issues/18454 https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import See the note at the bottom of this section warning about the usage of

enforcedPlatform

in the context of a consumable library.

With your help I've arrived at a happyish conclusion. I'll detail what I did as it might be useful for others. I made a configuration 'bom', had compileOnly, testImplementation and runtimeClasspath extendFrom bom. This had the effect that things I declare bom (i.e., actual boms), got used in all the places I wanted, but didn't leak outside of modules. I then modify the pom when I publish. Thanks for the help!

We use the exact same method to achieve that, we just called it “globalPlatforms”. Conceptually it’s closer to how maven handles boms, by applying them globally, whereas gradle scopes a platform to the configuration it was declared in. In the end it’s about convenience and not having to repeat yourself by declaring the bom over and over again. But I do understand why gradle chose to go the limited scope route. You have a lot more control over it that way.

val globalPlatforms by configurations.creating {
    isVisible = false
    isCanBeResolved = false
    isCanBeConsumed = false
}
configurations {
    configureEach {
        // resolvable configurations like compileClasspath, runtimeClasspath, ... will inherit global platforms
        // make sure we only apply to java modules
        if (isCanBeResolved && pluginManager.hasPlugin("java-base")) {
            extendsFrom(globalPlatforms)
        }
    }
}