.Swift Library Plugin configurations
image::swift-library-configurations.png[]

* The configurations in white are the ones a user should use to declare dependencies
* The configurations in pink, also known as consumable denoted by \(C), are the ones used when a component compiles, links, or runs against the library
* The configurations in blue, also known as resolvable denoted by \(R), are internal to the component, for its own use

.{cpp} Library Plugin configurations
image::cpp-library-configurations.png[]

* The configurations in white are the ones a user should use to declare dependencies
* The configurations in pink, also known as consumable denoted by \(C), are the ones used when a component compiles, links, or runs against the library
* The configurations in blue, also known as resolvable denoted by \(R), are internal to the component, for its own use

[[deactivate_included_build_substitutions]]
=== Deactivate included build substitutions for a configuration

- the <<declaring_dependencies.adoc#sec:resolvable-consumable-configs,outgoing configuration>> that is used as a variant source
- a customization action which allows you to _filter_ which variants are going to be published

    def "classifier and extension do not need to match file name"() {
        given:
        buildFile.text = """
            configurations {
                consumable("con") {
                    outgoing.artifact(file("foo.txt")) {
                        classifier = "HELLO"
                        extension = "123"
                    }
                    attributes {

<2> Assign the <<variant_attributes.adoc#sub:gradle_plugins_default_attributes,Gradle API version attribute>> to all <<declaring_dependencies.adoc#sec:resolvable-consumable-configs,consumable configurations>> of our Gradle7 variant. Gradle uses this information to determine which variant to select during plugin resolution.

// limitations under the License.

[[sec:abm_artifact_transforms]]
= Transforming dependency artifacts on resolution

As described in <<declaring_dependencies.adoc#sec:resolvable-consumable-configs,different kinds of configurations>>, there may be different variants for the same dependency.

Verification failures are also useful for tasks that need to report a failure even after producing useful output consumable by other tasks.

====
include::sample[dir="snippets/failures/verificationFailure/kotlin",files="build.gradle.kts[tags=verification-failure]"]

 *
 * <p>The notation <code>project(':project-a')</code> is similar to the syntax you use
 * when configuring a projectA in a multi-module gradle project.
 *
 * <p>Project dependencies are resolved by treating each consumable configuration in the target
 * project as a variant and performing variant-aware attribute matching against them.
 * However, in order to override this process, an explicit target configuration can be specified:

* Resolvable configurations should not have their resolution strategy, dependencies, hierarchy, etc. modified after they have been resolved.
* Consumable configurations should not have their dependencies, hierarchy, attributes, etc. modified after they have been published or consumed as a variant.