Open StefMa opened 3 years ago
It's hard to say. Since we defer to Gradle's dependency management it is a bit hidden from us.
This can sometimes occur due to the Gradle cache, where --refresh-dependencies
forces Gradle to query with the repositories for the latest version. Typically the cache expires after 24 hours, so usually this skew occurs shortly after a release when it retained some stale metadata.
Other times it is because of bad metadata on a repository. For example JCenter will proxy explicit versions to Maven Central, but not dynamic versions. Thus a +
version will observe a stale maven-metadata.xml
and give wrong results. This most often occurs when a project is listed on JCenter, e.g. so that the authors can observe the download stats, but the dependency is released to Central and it skews over time. I don't see anything quirky on JCenter, if that was the case.
Another possibility is if you have a resolution strategy that rejected a version. This might force com.squareup.moshi:moshi
but not its sibling dependencies. Gradle now resolves that by being able to declare them together as "platform dependencies" to tie their versions together. Without that, when resolving the resolution strategy might force moshi to your current version while allowing us to detect updates to the others. This is the most likely culprit, and you could skip your rules, e.g. by querying the task graph.
I have three moshi artifacts as a dependency:
com.squareup.moshi:moshi-kotlin-codegen:
com.squareup.moshi:moshi-adapters:
com.squareup.moshi:moshi:
All of them have (currently) the version
1.9.3
. The latest version is1.11.0
.While in the report
moshi-kotlin-codegen
andmoshi-adapters
are marked as outdated,moshi
is inside thecurrent
dependencies section: Outdated dependencies: Current dependencies:This is strange because all the artifacts are published and maintained by the same people.