Make it possible to use an ecosystem describer in more casesBefore this commit the describer would only be used if the same set of attributeswas found. This means that if the consumer added, or removed, one attribute, wewould lose the benefit of better user error messages. With this change, we tryto find the _best matching_ describer, if any.
Improve variant matching error messagesError messages prove to be difficult to interpret from a user point ofview. This commit tries to improve the situation by doing a couple ofthings:1. describing more clearly what the consumer is asking for. This includes,when possible (currently only in the Java ecosystem), interpreting theconsumer attributes as a human-readable description, instead of a rawlist of attributes.2. giving more context when possible. In particular, sometimes we failwith an ambiguous variant error selection, but we only list the remainingcandidates, not listing the ones which were actually discarded duringselection. This proved to be particularly complex to debug from varioususers (plugin authors and end-users).
Rewrite section on component metadata rules (#10735)The section was written when the very first version of rules wasintroduced and since then only marginally updated.This is a complete rewrite of the section focusing on explainingall the metadata modeling features of Gradle Module Metadatawhich can be utilized in rules to enrich existing metadata.The features are described on using real-world use cases.Related sections are also updated where applicable.
To avoid confusion, remove mention of "platform" from "target Java platform"We already have the "Java Platform" plugin which is something quitedifferent from the concept we want to express when using "target java platform".This is more often known as the "JVM version", or "target Java version". Weuse "JVM" because this is not specific to Java.