gradle-versions-plugin: Task Takes Too Long

@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>'
    }
}

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.

I have now removed an unused snapshot repo and sprinkled other repository definitions with stuff like …

            mavenContent {
                releasesOnly()
            }
            content {
                excludeGroupByRegex("com\\.mycompany.*")
            }

… and voila! the build times are down to mere minutes 😃