Is there a way to exclude dependencies from being checked?

[peterfigure]

My company doesn't use semver (🙄), eg:

The following dependencies have later release versions:
 - x.x:stream-data [master-2033 -> wshin-ch15834-incentive-22]
 - x.x.document:client [master-106 -> 1.1-TEST]

It's extremely slow to use Component Selection / rejectVersionIf rules (there are 1000s of versions) - is there a way to just exclude certain dependencies from being checked at all? eg. based on group coordinate?

[ben-manes]

We don't have exclusion rules, likely because its simplest to just force the current version and effectively mark it as up-to-date. For example if you keep a manifest then you could write it as,

dependencyUpdates.resolutionStrategy {
  force libraries.foobar
}

[peterfigure]

Thanks @ben-manes - I gave this a quick whirl:

tasks.named<DependencyUpdatesTask>("dependencyUpdates").configure {
    Libraries.AllCompanyDeps.forEach {
        resolutionStrategy {
            force(it)
        }
    }
}

but I still see the exact same output and it takes almost 4 minutes - was that would you would expect to see?

[ben-manes]

hmm, I am not sure then. I use this trick in Caffeine because the imported Guava test suite requires a certain dependency version, and it was not worth the effort to migrate after Guava updated its compatibility. That drops the later versions from the report.

Note that there our resolutionStrategy property is not composable. If you combine with rejectVersionIf, the last definition is used. This is a single field being set, not a collection of rules. That might be the mistake that causes the force to not be honored.

The slow resolution might be due to Gradle checking all of your repositories. You can use repository rules to direct it to the right repo, which might make it faster.

Another strategy might be to remove the dependency from the configuration prior to the updates task being run. That might be done by checking if this task is on the taskGraph and removing the dependencies programmatically. A little quirky, but usually the APIs make almost anything possible.

I have nothing against a PR to add exclusion support, if you prefer. Since it hasn't come up, I merely suspect there is a trivial workaround that might be good enough for you.

[JacksonBailey]

I have this problem as well. My company's versioning is to use branch-sha. I don't know exactly why this plugin is downloading the metadata for every version for these (maybe it always does and I haven't noticed), but it is very slow. Being able to tell this plugin, "Hey, if the group is com.blah.* just ignore it" would be useful.

I have been running the build for over ten minutes. It is still downloading artifacts from closed PRs from three years ago.

It seems to want to download everything. I don't really fully know how Maven/Artifactory expose everything or how Gradle checks it internally, but I would hope that there would be a way to decide whether to consider a version for upgrading based on the current version without getting history first.

[ben-manes]

We simply let Gradle resolve since they already build the dependency resolution logic (like routing through a secure proxy), else there can be NIH problems. This has the negative effect that since its not a case they've optimized for there are slowdowns like sequential resolution that are not prioritized by them to address.

You can use repository content filtering, configuration filtering, and the resolutionStrategy to control much of this. Most likely the branch-sha is violating the resolutionStrategy which causes Gradle to scan trying to find a match. That often happens when a snapshot repository was added but the rejectVersionIf disallows snapshots, so it scans because its not properly excluded in the configuration as a search target.

[ben-manes]

some examples in #505 that worked for others