Consistently use component level attributes
Component-level attributes were only used if the component metadata was using Gradle
metadata. This was particularly confusing, as it was possible to define a component-
level attribute in a component-metadata rule, but it would be ignored during matching.
It was possible, however, to add attributes on variants of Ivy or Maven metadata,
but then the error messages in case there wasn't any match was even more confusing:
"Because there are no configurations with attributes"
This commit modifies the resolution engine so that it's possible to use component
level attributes independently of whether the underlying component metadata was
constructed from Ivy, Maven or Gradle metadata. It also changes the error messages
to mention either "configuration" or "variant" depending on whether the matching
strategy was using variant-aware dependency management *or* legacy configurations.
It was confusing because we have the `IMPROVED_POM_SUPPORT` flag which activates
variant construction from Maven metadata. This meant that in practice, if the flag
was active, we were using variants, but still the component level attributes were
not taken into account. If the flag wasn't active, then we would fail with the
error above, despite the fact we had rules on "configuration backed variants".
The separation of configuration/variant in error messages makes it easier for
us to understand in which case we are, since this wasn't always obvious. If we
see "variant", then now we know that the selection failed using the variant-aware
matching. If we see "configuration", then we know it's using the legacy mode.
This commit also needed to make the difference between "this component has no
variant" and "this component doesn't provide any mapping to variants", therefore
the introduction of the `Optional` on `getVariantsForTraversal`. This gives us
the opportunity to give the correct error message in case of failure using
the legacy mode.
Last but not least, this introduces a change in the attributes visible on variants
**and** artifacts. Before this commit, dependending on whether metadata was
Gradle metadata, the "status" attribute would be found or not. Now, the component
level attributes are _always_ merged to variant and artifact attributes, which
means that it's consistent independently of the format. This can be a breaking
change, but a low risk one.
27 Apr 18 48b0a2d2120359a23f82e742f2ebca28a4f3a117
Do not pass variant attributes to `(single|multiple)Variants`
Instead, we make sure that the variant passed to the artifact set already contains the right set of
attributes. This involves wrapping the original `ComponentVariant` into a wrapper that will execute
the attribute rules lazily (and only once).
Signed-off-by: Cedric Champeau <email@example.com>
22 Dec 17 c96a1012a15f14dc0c7d8b29f64215da87ff9cc0