As explained in the section on variant aware matching, attributes give semantics to variants and are used by Gradle’s dependency management engine to select the best matching variant.

As a user of Gradle, attributes are often hidden as implementation details. But it might be useful to understand the standard attributes defined by Gradle and its core plugins.

As a plugin author, these attributes, and the way they are defined, can serve as a basis for building your own set of attributes in your ecosystem plugin.

Standard attributes defined by Gradle

Gradle defines a list of standard attributes used by Gradle’s core plugins.

Ecosystem-independent standard attributes

Table 1. Ecosystem-independent standard variant attributes
Attribute name Description Values compatibility and disambiguation rules

org.gradle.usage

Indicates main purpose of variant

Usage values built from constants defined in Usage

Following ecosystem semantics (e.g. java-runtime can be used in place of java-api but not the opposite)

org.gradle.category

Indicates the category of this software component

Category values built from constants defined in Category

Following ecosystem semantics (e.g. library is default on the JVM, no compatibility otherwise)

org.gradle.libraryelements

Indicates the contents of a org.gradle.category=library variant

LibraryElements values built from constants defined in LibraryElements

Following ecosystem semantics(e.g. in the JVM world, jar is the default and is compatible with classes)

org.gradle.docstype

Indicates the contents of a org.gradle.category=documentation variant

DocsType values built from constants defined in DocsType

No default, no compatibility

org.gradle.dependency.bundling

Indicates how dependencies of a variant are accessed.

Bundling values built from constants defined in Bundling

Following ecosystem semantics (e.g. in the JVM world, embedded is compatible with external)

org.gradle.verificationtype

Indicates what kind of verification task produced this output.

VerificationType values built from constants defined in VerificationType

No default, no compatibility

When the Category attribute is present with the incubating value org.gradle.category=verification on a variant, that variant is considered to be a verification-time only variant.

These variants are meant to contain only the results of running verification tasks, such as test results or code coverage reports. They are not publishable, and will produce an error if added to a component which is published.

Table 2. Ecosystem-independent standard component attributes
Attribute name Description Values compatibility and disambiguation rules

org.gradle.status

Component level attribute, derived

Based on a status scheme, with a default one existing based on the source repository.

Based on the scheme in use

JVM ecosystem specific attributes

In addition to the ecosystem independent attributes defined above, the JVM ecosystem adds the following attribute:

Table 3. JVM ecosystem standard component attributes
Attribute name Description Values compatibility and disambiguation rules

org.gradle.jvm.version

Indicates the JVM version compatibility.

Integer using the version after the 1. for Java 1.4 and before, the major version for Java 5 and beyond.

Defaults to the JVM version used by Gradle, lower is compatible with higher, prefers highest compatible.

org.gradle.jvm.environment

Indicates that a variant is optimized for a certain JVM environment.

Common values are standard-jvm and android. Other values are allowed.

The attribute is used to prefer one variant over another if multiple are available, but in general all values are compatible. The default is standard-jvm.

org.gradle.testsuite.name

Indicates the name of the TestSuite that produced this output.

Value is the name of the Suite.

No default, no compatibility

org.gradle.testsuite.target.name

Indicates the name of the TestSuiteTarget that produced this output.

Value is the name of the Target.

No default, no compatibility

org.gradle.testsuite.type

Indicates the type of test suite (unit test, integration test, performance test, etc.)

TestSuiteType values built from constants defined in TestSuiteType or other custom values for user-defined test suite types.

No default, no compatibility

The JVM ecosystem also contains a number of compatibility and disambiguation rules over the different attributes. The reader willing to know more can take a look at the code for org.gradle.api.internal.artifacts.JavaEcosystemSupport.

Native ecosystem specific attributes

In addition to the ecosystem independent attributes defined above, the native ecosystem adds the following attributes:

Table 4. Native ecosystem standard component attributes
Attribute name Description Values compatibility and disambiguation rules

org.gradle.native.debuggable

Indicates if the binary was built with debugging symbols

Boolean

N/A

org.gradle.native.optimized

Indicates if the binary was built with optimization flags

Boolean

N/A

org.gradle.native.architecture

Indicates the target architecture of the binary

MachineArchitecture values built from constants defined in MachineArchitecture

None

org.gradle.native.operatingSystem

Indicates the target operating system of the binary

OperatingSystemFamily values built from constants defined in OperatingSystemFamily

None

Gradle plugin ecosystem specific attributes

For Gradle plugin development, the following attribute is supported since Gradle 7.0. A Gradle plugin variant can specify compatibility with a Gradle API version through this attribute.

Table 5. Gradle plugin ecosystem standard component attributes
Attribute name Description Values compatibility and disambiguation rules

org.gradle.plugin.api‑version

Indicates the Gradle API version compatibility.

Valid Gradle version strings.

Defaults to the currently running Gradle, lower is compatible with higher, prefers highest compatible.

Declaring custom attributes

If you are extending Gradle, e.g. by writing a plugin for another ecosystem, declaring custom attributes could be an option if you want to support variant-aware dependency management features in your plugin. However, you should be cautious if you also attempt to publish libraries. Semantics of new attributes are usually defined through a plugin, which can carry compatibility and disambiguation rules. Consequently, builds that consume libraries published for a certain ecosystem, also need to apply the corresponding plugin to interpret attributes correctly. If your plugin is intended for a larger audience, i.e. if it is openly available and libraries are published to public repositories, defining new attributes effectively extends the semantics of Gradle Module Metadata and comes with responsibilities. E.g., support for attributes that are already published should not be removed again, or should be handled in some kind of compatibility layer in future versions of the plugin.

Creating attributes in a build script or plugin

Attributes are typed. An attribute can be created via the Attribute<T>.of method:

build.gradle.kts
// An attribute of type `String`
val myAttribute = Attribute.of("my.attribute.name", String::class.java)
// An attribute of type `Usage`
val myUsage = Attribute.of("my.usage.attribute", Usage::class.java)
build.gradle
// An attribute of type `String`
def myAttribute = Attribute.of("my.attribute.name", String)
// An attribute of type `Usage`
def myUsage = Attribute.of("my.usage.attribute", Usage)

Attribute types support most Java primitive classes; such as String and Integer; Or anything extending org.gradle.api.Named. Attributes should always be declared in the attribute schema found on the dependencies handler:

build.gradle.kts
dependencies.attributesSchema {
    // registers this attribute to the attributes schema
    attribute(myAttribute)
    attribute(myUsage)
}
build.gradle
dependencies.attributesSchema {
    // registers this attribute to the attributes schema
    attribute(myAttribute)
    attribute(myUsage)
}

Registering an attribute with the schema is required in order to use Compatibility and Disambiguation rules that can resolve ambiguity between multiple selectable variants during Attribute Matching.

Each configuration has a container of attributes. Attributes can be configured to set values:

build.gradle.kts
configurations {
    create("myConfiguration") {
        attributes {
            attribute(myAttribute, "my-value")
        }
    }
}
build.gradle
configurations {
    myConfiguration {
        attributes {
            attribute(myAttribute, 'my-value')
        }
    }
}

For attributes which type extends Named, the value of the attribute must be created via the object factory:

Example 4. Named attributes
build.gradle.kts
configurations {
    "myConfiguration" {
        attributes {
            attribute(myUsage, project.objects.named(Usage::class.java, "my-value"))
        }
    }
}
build.gradle
configurations {
    myConfiguration {
        attributes {
            attribute(myUsage, project.objects.named(Usage, 'my-value'))
        }
    }
}

Attribute matching

Attribute compatibility rules

Attributes let the engine select compatible variants. There are cases where a producer may not have exactly what the consumer requests but has a variant that can be used.

For example, if the consumer is asking for the API of a library and the producer doesn’t have an exactly matching variant, the runtime variant could be considered compatible. This is typical of libraries published to external repositories. In this case, we know that even if we don’t have an exact match (API), we can still compile against the runtime variant (it contains more than what we need to compile but it’s still ok to use).

Gradle provides attribute compatibility rules that can be defined for each attribute. The role of a compatibility rule is to explain which attribute values are compatible based on what the consumer asked for.

Attribute compatibility rules have to be registered via the attribute matching strategy that you can obtain from the attributes schema.

Attribute disambiguation rules

Since multiple values for an attribute can be compatible, Gradle needs to choose the "best" candidate between all compatible candidates. This is called "disambiguation".

This is done by implementing an attribute disambiguation rule.

Attribute disambiguation rules have to be registered via the attribute matching strategy that you can obtain from the attributes schema, which is a member of DependencyHandler.

Variant attribute matching algorithm

Finding the best variant can get complicated when there are many different variants available for a component and many different attributes. Gradle’s dependency resolution engine performs the following algorithm when finding the best result (or failing):

  1. Each candidate’s attribute value is compared to the consumer’s requested attribute value. A candidate is considered compatible if its value matches the consumer’s value exactly, passes the attribute’s compatibility rule or is not provided.

  2. If only one candidate is considered compatible, that candidate wins.

  3. If several candidates are compatible, but one of the candidates matches all of the same attributes as the other candidates, Gradle chooses that candidate. This is the candidate with the "longest" match.

  4. If several candidates are compatible and are compatible with an equal number of attributes, Gradle needs to disambiguate the candidates.

    1. For each requested attribute, if a candidate does not have a value matching the disambiguation rule, it’s eliminated from consideration.

    2. If the attribute has a known precedence, Gradle will stop as soon as there is a single candidate remaining.

    3. If the attribute does not have a known precedence, Gradle must consider all attributes.

  5. If several candidates still remain, Gradle will start to consider "extra" attributes to disambiguate between multiple candidates. Extra attributes are attributes that were not requested by the consumer but are present on at least one candidate. These extra attributes are considered in precedence order.

    1. If the attribute has a known precedence, Gradle will stop as soon as there is a single candidate remaining.

    2. After all extra attributes with precedence are considered, the remaining candidates can be chosen if they are compatible with all of the non-ordered disambiguation rules.

  6. If several candidates still remain, Gradle will consider extra attributes again. A candidate can be chosen if it has the fewest number of extra attributes.

If at any step no candidates remain compatible, resolution fails. Additionally, Gradle outputs a list of all compatible candidates from step 1 to help with debugging variant matching failures.

Plugins and ecosystems can influence the selection algorithm by implementing compatibility rules, disambiguation rules and telling Gradle the precedence of attributes. Attributes with a higher precedence are used to eliminate compatible matches in order.

For example, in the Java ecosystem, the org.gradle.usage attribute has a higher precedence than org.gradle.libraryelements. This means that if two candidates were available with compatible values for both org.gradle.usage and org.gradle.libraryelements, Gradle will choose the candidate that passes the disambiguation rule for org.gradle.usage.