How can I configure a single dependency into multi...
# community-support
i
How can I configure a single dependency into multiple configurations in a single line? Currently, I have:
Copy code
dependencies {
    dokka(projects.a)
    dokka(projects.b)
    kover(projects.a)
    kover(projects.b)
    nmcpAggregation(projects.a)
    nmcpAggregation(projects.b)
    // …
}
which is not fun to maintain when there are dozens of projects. Instead, I'd rather have:
Copy code
dependencies {
    library(projects.a)
    library(projects.b)
}
where
library
is a custom configuration that applies its contents to
dokka
,
kover
and
nmcpAggregation
. I've tried:
Copy code
val library by configurations.registering {
	isCanBeResolved = false
	isCanBeConsumed = false
}

configurations.dokka.get().extendsFrom(library.get())
configurations.kover.get().extendsFrom(library.get())
configurations.nmcpAggregation.get().extendsFrom(library.get())
but that only seems to partially work. I'm testing it in a build that looks like
Copy code
Root project 'Kotlin-example'
+--- Project ':app'
+--- Project ':core'
+--- Project ':mkdocs'
\--- Project ':plugin'
where the root project contains
Copy code
dependencies {
    library(projects.core)
}
The NMCP plugin seems to pick up the dependency:
Copy code
$ … dependencies --configuration nmcpAggregation
nmcpAggregation
\--- project :core FAILED
However, the Kover configuration gets the current project for some reason:
Copy code
$ … dependencies --configuration kover 
kover (n)
\--- project Kotlin-example (n)
And the Dokka plugin doesn't get anything at all:
Copy code
$ … dependencies --configuration dokka
dokka - Fetch all Dokka files from all configurations in other subprojects. (n)
No dependencies
What's going on? If
extendsFrom
isn't the correct way to do this, what is?
p
It should work. Will try it in a few minutes but it looks correct to me.
1
m
@Ivan CLOVIS Canet do you have a branch with your current code?
e
this won't affect the outcome but for reference, you should ideally use configurations.dependencyScope instead of manipulating
isCanBeResolved
and
isCanBeConsumed
v
you should ideally use configurations.dependencyScope instead
Which is still
@Incubating
though and thus many people refuse to use it already. 😉
1
But regarding the original question, as @Philip W said, it is correct and also works correct. You just misinterpret the
dependencies
output.
👀 1
dokka
and
kover
are not resolvable, so you only see the dependencies declared directly on them and that's it. If you create a resolvable configuration that extends from
dokka
it will contain the dependency for example.
For example try
Copy code
val library by configurations.dependencyScope("library")
val resolvable by configurations.resolvable("resolvable") {
    extendsFrom(library)
}
val nonResolvable by configurations.dependencyScope("nonResolvable") {
    extendsFrom(library)
}
val resolvableNonResolvable by configurations.resolvable("resolvableNonResolvable") {
    extendsFrom(nonResolvable)
}
dependencies {
    library(project)
}
And you will see
Copy code
library (n)
\--- project showcase (n)

nonResolvable (n)
No dependencies

resolvable
\--- root project : (*)

resolvableNonResolvable
\--- root project : (*)
i
@Martin Branch
nmcp
in repository
<https://gitlab.com/opensavvy/automation/gradle-conventions.git>
, more specifically the latest commit. The test project is available with
./gradlew -p examples/kotlin --include-build ../.. tasks
, that repository is a bit of a mess.
🙏 1
@Vampire you're right, it seems to work for Dokka. It halfway works for Kover, but that's probably a Kover problem more than a dependency problem.
Thanks!
👌 2