Provider

A container object that provides a value of a specific type. The value can be retrieved using one of the query methods such as get or getOrNull.

A provider may not always have a value available, for example when the value may not yet be known but will be known at some point in the future. When a value is not available, isPresent returns false and retrieving the value will fail with an exception.

A provider may not always provide the same value. Although there are no methods on this interface to change the value, the provider implementation may be mutable or use values from some changing source. A provider may also provide a value that is mutable and that changes over time.

A provider may represent a task output. Such a provider carries information about the task producing its value. When this provider is attached to an input of another task, Gradle will automatically determine the task dependencies based on this connection.

A typical use of a provider is to pass values from one Gradle model element to another, e.g. from a project extension to a task, or between tasks. Providers also allow expensive computations to be deferred until their value is actually needed, usually at task execution time.

There are a number of ways to create a Provider instance. Some common methods:

• A number of Gradle types, such as Property, extend Provider and can be used directly as a provider.
• Calling map to create a new provider from an existing provider.
• Using the return value of register, which is a provider that represents the task instance.
• Using the methods on org.gradle.api.file.Directory and org.gradle.api.file.DirectoryProperty to produce file providers.
• By calling provider or provider to create a new provider from a Callable.

For a provider whose value can be mutated, see Property and the methods on org.gradle.api.model.ObjectFactory.

Note: This interface is not intended for implementation by build script or plugin authors.

Configuration Cache

The Configuration Cache handles providers in a special way. When a provider is discovered to be part of the cached build configuration (e.g. when it is a task input), one of two things happen:

• Cache by value. The value of the provider is computed and stored. This typically happens if the provider is derived from purely configuration-time data.
• Cache by computation. The provider is stored as a lazy computation. For example, if the provider is a result of map, then the origin provider (on which map was called) and the Transformer (including its captured variables) are stored. Note that the origin provider may still be cached by value. After loading from cache, the value is only computed if requested (e.g. with get), as usual. This typically happens when the value of the provider is only available at execution time (e.g. derived from a task output) or if it is sourced from the environment (e.g. a system property or an environment variable).

The Configuration Cache operates under the assumption that most of the stored providers will be used at execution time, so it attempts to cache values of as many providers as possible without introducing more build configuration inputs. However, the exact definition of which provider to cache is intentionally left underspecified. For example, even a provider derived from a system property provider may be cached by value if that system property is already an input.

Following the rules below ensures that your Providers remain configuration-cache compatible regardless of applied optimizations.

1. Providers returned by provider or provider are always computed at configuration time. The Callable may capture arbitrary data types and freely call configuration-time-only APIs. This is the preferred way to bridge non-lazy and lazy APIs, like passing getVersion into task's input Property.
2. Any value returned (provided) by the provider must conform to the configuration cache requirements. This requirement may not be enforced when the value is an intermediate result and the Configuration Cache runs the computation chain to cache the end result.
3. Any value captured by the computation of the provider (e.g. a variable captured by the Transformer lambda supplied to map) must conform to the configuration cache requirements, except the Callable of provider or provider. This requirement may not be enforced when the Configuration Cache runs the computation chain containing non-conforming transformation to cache the end result.
4. The computation of the provider (except the Callable of provider or provider) should not invoke configuration-time only APIs. This requirement may not be enforced when the Configuration Cache runs the computation chain containing non-conforming transformation to cache the end result.
5. The computation of the provider should not use external state (read system properties, environment variables, or files) to avoid introducing accidental build configuration inputs. Preferably, these should be obtained through providers returned by ProviderFactory and zip should be used to mix them into the computation chain. The Callable of provider or provider must ignore this requirement if the external state is used by configuration-time-only API because adding an input is unavoidable in this case.

Configuration Cache's support of providers that do not conform to these requirements is unspecified and may change between Gradle versions or depending on when values of the providers are obtained during build.

Some providers returned by Gradle APIs provide types that cannot be configuration-cached, for example TaskProvider or Provider<Configuration>. Such providers should not be used as part of the cached build configuration directly, but the providers returned by their map or flatMap can be if their value or the downstream transformation chain conforms to the requirements above. In most cases it is also safe to add these non-cacheable providers to ConfigurableFileCollections when it makes sense.

Parameters

Inheritors