Task Takes Too Long

I’ve been using this tool a long time now. And I’ve noticed that it now takes really long time to check dependencies. I haven’t run this tool for a while now, but today took 4 hours to complete the task

Generated report file build/dependencyUpdates/report.txt

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.1.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 4h 11m 4s

Am I missing a flag or configuration? Thanks

[ldimitroff]

@ben-manes @henrik242 I’ve fixed locally the issue by removing a snapshot repository before running the dependency updates task. Noticed that the task was trying to get the information about every verion listed in that repository. It was going decremental instead of checkging the latest version 🤷‍♂️

tasks.dependencyUpdates.doFirst {
    project.repositories.removeAll {
        it instanceof MavenArtifactRepository && it.url.toString() == '<MY.SNAPSHOT.REPO>'
    }
}

[ben-manes]

Would it be possible to log some statistics of the most time consuming tasks/repositories/artifacts?

@henrik242 Unfortunately we can’t, because the resolution is handled by Gradle itself. We don’t reimplement their dependency management, but plug into it via a cloned configuration and rewritten dependency versions. Since the APIs don’t expose that data, we couldn’t provide hints beyond looking at the --info or --debug logs to see Gradle’s messaging.

Noticed that the task was trying to get the information about every version listed in that repository. It was going decremental instead of checking the latest version

@ldimitroff This is how a resolution strategy works to resolve, where it pulls all of the versions (typically from maven-metadata.xml), orders in descending order, and then filters by the component selection rule until a version passes (or fails as unresolvable). If Gradle is making a fetch per version then that would be slow. It may be that if you declare the repository as snapshot only, gradle might skip over it. However, since we use a dynamic query (+) it might try regardless so your trick is excellent.