Enhancement request to exclude configurations from check

[bwmeier]

Certain plugins create their own configurations for resolution, and these configurations are picked up by the plugin and merged into the report. It causes some level of confusion in many circumstances when reading the reports.

For example, spotbugs plugin generates several configurations (Spotbugs, SpotbugsPlugins, SpotbugsSlf4j), which cause weirdness like duplicate entries for slf4j, entries for unknown libraries that are not directly configured, etc. Similar things happen with com.diffplug.spotless, and other similar plugins.

It would be good if it was possible to either specify the specific configurations to resolve, or specify configurations to exclude when executing the plugin.

[ben-manes]

I've wondered about whether this would be useful in the past, too. These are part of your build that you might want to manage, e.g. to avoid supply chain attacks. If someone feels strongly in favor of this then a PR (with tests) is welcome.

[bwmeier]

I might take a stab at this if I have time to dig into your code. It won't be anytime real soon, though, so if someone else has a chance to look at it, I'd appreciate it.

[ben-manes]

You'd most likely add a filter predicate here or in the resolveProjects method, https://github.com/ben-manes/gradle-versions-plugin/blob/8c1ee4ba3f78f2791331670ae1b388c7eaf9abc2/gradle-versions-plugin/src/main/kotlin/com/github/benmanes/gradle/versions/updates/DependencyUpdates.kt#L38-L43

A bit later we iterate over the configurations, creating a Resolver, and aggregate the results. That is then passed down to a reporter to print it out. Unfortunately we don't capture the configuration that the dependency update is associated with for the report, which might be helpful if debugging (though Gradle's dependency tree is usually good enough).

I would lean towards a predicate instead of an allow/deny list as a bit more flexible. If too verbose then a convenience option built on that would be okay, like how rejectVersionIf is shorthand for the full resolutionStrategy.

[bh-tt]

I might take a look at this, as I have several hundred projects that I need to update and I'd like to resolve updates for the 3 or so relevant configurations (classpaths for compile, test and integrationtest). Especially Quarkus is bad in this regard, as it adds about 25 additional configurations, each with ~15 or so direct dependencies.

[bh-tt]

Ok my kotlin needs work, but this should come down to adding an additional Spec<Configuration> parameter to DependencyUpdates (and Input in the DependencyUpdatesTask). That it.configurations.toLinkedHashSet() call can then be replaced by it.configurations.matching(configurationFilter).toLinkedHashSet().

[bh-tt]

A full clean build just went from 150 seconds to 110 by excluding some plugin configurations.