return conf;
    }

    /**
     * Ensures the target variant matches the request attributes and is consumable. This needs to be called
     * for variants that are selected by means other than attribute matching.
     *
     * Note: This does not need to be called for variants selected via attribute matching, since
     * attribute matching ensures selected variants are compatible with the requested attributes.
     */

            .stream()
            .flatMap(variant -> variant.prepareForArtifactResolution().getArtifactVariants().stream())
            .map(variant -> new DefaultResolvedVariantResult(
                component.getId(),
                Describables.of(variant.getName()),
                component.getAttributeDesugaring().desugar(variant.getAttributes().asImmutable()),

        List<TestVariant> variants = new ArrayList<TestVariant>();
        variants.add(TestVariant.tapiCurrent(rootId, discoveryRequest));
        variants.add(TestVariant.selected(rootId, discoveryRequest));
        variants.add(TestVariant.tapiTargetLoaded(rootId, discoveryRequest));

        return variants;
    }

  - Configuration ':a:default' variant v1:
      - Unmatched attribute:
          - Doesn't say anything about usage (required 'compile')
  - Configuration ':a:default' variant v2:
      - Unmatched attribute:
          - Doesn't say anything about usage (required 'compile')""")
    }

The following statements must hold for the variants:

- Variant name must be unique per module
- Each variant must have at least one attribute
- Two variants cannot have the same attributes and capabilities
- If there is at least one dependency in any variant, at least one must carry version information

### `attributes` value

[[sec:cpp_application_task_variants]]
=== Variant-dependent Tasks

The {cpp} Application Plugin creates tasks based on the variants of the application component.
Read the <<building_cpp_projects.adoc#sec:introducing_build_variants-cpp,introduction to build variants>> for more information.
The following diagram shows the relationship between variant-dependent tasks.

.{cpp} Application Plugin variant-dependent task graph

[[sec:swift_application_task_variants]]
=== Variant-dependent Tasks

The Swift Application Plugin creates tasks based on the variants of the application component.
Read the <<building_swift_projects.adoc#sec:introducing_build_variants-swift,introduction to build variants>> for more information.
The following diagram shows the relationship between variant-dependent tasks.

.Swift Application Plugin variant-dependent task graph

        );
    }

    private void writeVariants() throws IOException {
        List<ModuleMetadataSpec.Variant> variants = metadata.variants;
        if (variants.isEmpty()) {
            return;
        }
        writeArray("variants", () -> {
            for (ModuleMetadataSpec.Variant variant : variants) {
                if (variant instanceof ModuleMetadataSpec.LocalVariant) {

[[sec:cpp_unit_test_task_variants]]
=== Variant-dependent Tasks

The {cpp} Unit Test Plugin creates tasks based on the variants of the unit test component.
Read the <<building_cpp_projects.adoc#sec:introducing_build_variants-cpp,introduction to build variants>> for more information.
The following diagrams show the relationship between variant-dependent tasks.

.{cpp} Unit Test Plugin variant-dependent task graph

        artifact2.classifier >> ""
        artifact2.extension >> "jar"
        def variant1 = createVariant([artifact1], [], 'api')
        def variant2 = createVariant([artifact2], [], 'runtime')
        def component = Stub(SoftwareComponentInternal)
        component.usages >> [variant1, variant2]
        def mavenArtifact = Mock(MavenArtifact)
        mavenArtifact.file >> artifactFile