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.