Not sure if I should post this here or in <#C3PQML...

# gradle

[robstoll]

Not sure if I should post this here or in #multiplatform. How can I exclude a transitive dependency from all sourceSets?

[ephemient]

doesn't make much sense, configurations (not sourceSets) have dependencies

[robstoll]

maybe I am better of asking in #multiplatform then, when you use the kotlin MPP plugin, then you specify dependencies for sourcesets

[robstoll]

I am sure the kotlin plugin uses configurations in the end. Do you know how to exclude a transitive dependency from all dependencies defined in all configurations?

[ephemient]

the plugin creates various configurations per sourceSet. depenencies are still on configurations, not sourceSets.

[robstoll]

good, so my guess was correct. Any idea how to do it with configurations?

[ephemient]

what's bringing the dependency in? just exclude it there, e.g.

dependencies {
    implementation("com.foo:foo:version") {
        exclude(group = "com.bar", module = "bar")
    }
}

[robstoll]

this one I know and is my current approach, but I don't want to repeat the same over and over again. Thus the question, if there isn't something more practical

[turansky]

https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html

[ephemient]

resolutionStrategy can't delete a dependency, just change what it resolves to

[robstoll]

that's already not too bad, will solve at least some part (where I exclude because I want one specific version). But in other cases I want to exclude a runtimeOnly dependency because I want to use another as substitute

[robstoll]

or is there maybe a way to do someting like substitute module('org.gradle:api') with nothing

[robstoll]

🙂

[ephemient]

well, define your own nothing project and sure

[turansky]

runtimeOnly is also configuration

[ephemient]

you could theoretically do

configurations.all { it.exclude(mapOf("group" to "com.bar", "module" to "bar")) }

but why?

[robstoll]

ok, will take a look. Thanks both for your help

[turansky]

If can specify rule special for runtimeOnly configuration

[robstoll]

e.g. you use slf4j and want to use a different backend than some libraries have chosen.

[Vampire]

Then the first thing is to report a bug to those libraries. Any library having an slf4j implementation as dependency has a clear bug. 🙂

[Vampire]

And then I would use a component metadata rule and not an exclude.

[Vampire]

Excludes are always used to solve symptoms of problems for which better solutions exist in Gradle, this not Maven after all. 😄

[Vampire]

You would use component metadata rules to give all slf4j implementations the same capability, so that there is a resolution error if multiple end up in the same configuration like shown for log4j at https://docs.gradle.org/current/userguide/userguide_single.html#adding_missing_capabilities_to_detect_conflicts and following the links for concrete example of how to model it and how to resolve the conflict.

[robstoll]

🤔 metada rules... sounds interesting, I need to have a closer look. Thanks for the hint.
Regarding a predefined slf4j implementation which is a runtimeOnly dependency: I never saw this as bug since a simple exclude suffices but I see your point :)

[Vampire]

If you need an exclude, it is a bug.
Either the lib needs that thing at runtime or it doesn't.
And in cases like slf4j implementation or log4j implementation, it is just non-sense to have the implementation as dependency in a library.
The downstream projects should choose the concrete implementation.
That's the whole sense of slf4j-api and log4j-api.
A lib uses these apis and the bottom-most downstream project decides which concrete implementation aggregates the log messages.