- changed 13 files
Consider the derivation strategy when requesting component metadataGradle has a single, build scoped cache for dependency metadata. It'susing a build cache scope because component metadata is quite expensiveto read and process. However, component metadata _may_ be differentbased on the plugins applied on a project. For example, Java projectsapply what we call a "Java derivation strategy", which is capableof transforming regular POM files into so-called "platforms" butmore importantly, they are what map the different Maven scopes toactual "variants" in variant-aware dependency management.The problem is that it's not a requirement that all projects areJava projects. It is possible to have native subprojects, or projectswhich do _not_ apply the Java base plugin. While it's in general anerror to have a project which wants to perform "Java dependencyresolution" not to apply the Java derivation strategy, there areconsequences in not doing so. In particular, Gradle becomes orderdependent: if a subproject which does not apply the derivationstrategy resolves a module first, then subsequent resolutions forprojects which _do_ apply the derivation strategy would get wrongmetadata.To avoid this, this commit makes sure that when we consume modulemetadata, we actually use the derivation strategy as part of theprocessed metadata cache key.This does _not_ fix the fact that the consumers _should have_ appliedthe derivation strategy and will make realizing this harder, but it_does_ fix the inconsistency in resolution, which is probably amuch bigger issue (for caching and reproducibility).