FYI: <https://www.sonatype.com/blog/maven-central-...
# dependency-management
t
c
not mentioned in the article: ephemeral build systems are a common cause of needing to re-download artifacts/dependencies from source (in combination with not using a caching repository proxy). Educating users on how to cache dependencies in common ephemeral cases would help. For example, a few extra lines in a GitHub Actions workflow will enable Gradle caching of resolved artifacts with the setup-gradle action.
3
d
But why can't we have a signed content distribution mechanism, so that a CI such github can allow users to share a regular caching proxy and properly validate the content they received. Then extend this to help mitigate supply chain concerns with all publications. Setup Gradle action only improves that one workflow while it stores the cache data. Also no breakdown in article in client technology in use at worst offenders, maybe Gradle is not the cause of the problem, but Maven due to it being difficult (and tedious) to solve the problem on a cloud hosted CI platform.
c
It would be helpful to see a breakdown by say user agent (Gradle identifies itself, its version & jvm info in user agent, not sure what maven or other consumers do).
There is also the JetBrains cache-redirector that can be used to avoid a direct dependency on Maven Central (settings.gradle.kts):
Copy code
pluginManagement {
    repositories { maven("<https://cache-redirector.jetbrains.com/plugins.gradle.org>") }
}

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories { maven("<https://cache-redirector.jetbrains.com/repo1.maven.org/maven2>") }
}