Exclude metadata configurations from htmlDependencyReport

Help/Discuss
1

Hello,

I’m trying to exclude the *metadata build configurations (e.g. apiDependenciesMetadata) from the htmlDependencyReport as they contain dependencies with status FAILED and just seem irrelevant for the actual built application. The project is a simple Kotlin Spring Boot application btw.

I first tried to set the configurations property of the task, but while that had an effect on the console output, it didn’t affect the generated report files.

tasks.withType<HtmlDependencyReportTask>().configureEach {
    configurations = project.configurations.filter { config ->
        config.isCanBeResolved && !config.name.contains("Metadata")
    }.toSet()
}

One approach, that does seem to do the job, is to set the resolvable property on the configuration to false. This will not remove the configuration entirely, but there won’t be any dependencies listed for it.

configurations.named("apiDependenciesMetadata") {
    isCanBeResolved = false
}

However, I’m wondering whether this has any unintended side effects or other negative consequences? I did not find any effects on the build application / published libraries or when using the module as (api) dependency so far, but still worried about possible issues caused by that.

So, I’m curious and need your help:

Is the workaround (setting configuration to resolvable = false) a safe thing to do? Which consequences does it have (if any)? Are there any better ways to exclude the *metadata configurations from the dependency report?

Thanks for your support!

2

as they contain dependencies with status FAILED

That sounds like a bug.
Maybe https://youtrack.jetbrains.com/issue/KT-68447 if you are not on a recent KGP version or similar to that.

and just seem irrelevant for the actual built application.

They are not, but what they are for, you have to ask the Kotlin maintainers.

I first tried to set the configurations property of the task

Like that it is a bit bad, because Gradle transitions to treating the configuration container lazy and you completely break that laziness by doing so.
But you might not have a different chance unless the provider-api migration that hopefully comes in Gradle 10.
But at least if you don’t break task-configuration avoidance for that task, it it at least only done when all configurations are anyway needed as that task gets executed somewhen.

That the configuration change works on the text output but not on the HTML output sounds like a bug you should report to Gradle if there is no ticket for it yet.

One approach, that does seem to do the job, is to set the resolvable property on the configuration to false. This will not remove the configuration entirely, but there won’t be any dependencies listed for it.

And thereby you most probably break something in KGP.
You should never change the role of a configuration and in the future this would also result in a hard error if you try to.

Is the workaround (setting configuration to resolvable = false) a safe thing to do?

Most probably not, but you need to ask Kotlin maintainers, but I’d really wonder if it is.

Are there any better ways to exclude the *metadata configurations from the dependency report?

Probably not, except for getting the Gradle bug fixed.