https://kotlinlang.org
Join Slack
Not sure if I should post this here or in <#C3PQML5NU|multiplatform>. How can I exclude a transitive...
# gradle
r
Not sure if I should post this here or in #multiplatform. How can I exclude a transitive dependency from all sourceSets?
e
doesn't make much sense, configurations (not sourceSets) have dependencies
r
maybe I am better of asking in #multiplatform then, when you use the kotlin MPP plugin, then you specify dependencies for sourcesets
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?
e
the plugin creates various configurations per sourceSet. depenencies are still on configurations, not sourceSets.
r
good, so my guess was correct. Any idea how to do it with configurations?
e
what's bringing the dependency in? just exclude it there, e.g.
Copy code
dependencies {
    implementation("com.foo:foo:version") {
        exclude(group = "com.bar", module = "bar")
    }
}
r
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
t
e
resolutionStrategy can't delete a dependency, just change what it resolves to
r
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
or is there maybe a way to do someting like 
substitute module('org.gradle:api') with nothing
🙂
e
well, define your own 
nothing
project and sure
t
runtimeOnly
is also configuration
e
you could theoretically do
Copy code
configurations.all { it.exclude(mapOf("group" to "com.bar", "module" to "bar")) }
but why?
r
ok, will take a look. Thanks both for your help
t
If can specify rule special for 
runtimeOnly
configuration
r
e.g. you use slf4j and want to use a different backend than some libraries have chosen.
v
Then the first thing is to report a bug to those libraries. Any library having an 
slf4j
implementation as dependency has a clear bug. 🙂
And then I would use a component metadata rule and not an exclude.
Excludes are always used to solve symptoms of problems for which better solutions exist in Gradle, this not Maven after all. 😄
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.
r
🤔 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 :)
v
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.
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by