Gradle calls the <<declaring_dependencies.adoc#sec:what-are-dependency-configurations,scope of a dependency>> a _configuration_.

Repositories offer dependencies in multiple formats.
For information about the formats supported by Gradle, see <<declaring_dependencies.adoc#sec:dependency-types,dependency types>>.

Metadata describes dependencies.

[[sec:configurations_java_tutorial]]
== Using dependency configurations

A link:{groovyDslPath}/org.gradle.api.artifacts.Configuration.html[Configuration] is a named set of dependencies and artifacts. There are three main purposes for a _configuration_:

Declaring dependencies::

include::sample[dir="snippets/swift/basic/groovy",files="build.gradle[tags=swift-dependency-mgmt]"]
====

The Gradle terminology for the three elements is as follows:

 * _Configuration_ (ex: `implementation`) - a named collection of dependencies, grouped together for a specific goal such as compiling or linking a module
 * _Project reference_ (ex: `project(':common')`) - the project referenced by the specified path

include::sample[dir="snippets/cpp/basic/groovy",files="build.gradle[tags=cpp-dependency-mgmt]"]
====

The Gradle terminology for the three elements is as follows:

 * _Configuration_ (ex: `implementation`) - a named collection of dependencies, grouped together for a specific goal such as compiling or linking a module
 * _Project reference_ (ex: `project(':common')`) - the project referenced by the specified path

====

<1> Add a repository to resolve the codec library - this can be a different repository than the one used to build the `CreateMD5` task class.
<2> Add a _configuration_ to resolve our codec library version.
<3> Configure an alternate, compatible version of https://commons.apache.org/proper/commons-codec/[Apache Commons Codec].
<4> Configure the `md5` task to use the configuration as its classpath.

====

The Gradle terminology for the three elements is as follows:

 * _Repository_ (ex: `mavenCentral()`) — where to look for the modules you declare as dependencies
 * _Configuration_ (ex: `implementation`) — a named collection of dependencies, grouped together for a specific goal such as compiling or running a module — a more flexible form of Maven scopes

This demonstrates the <<../userguide/cross_project_publications.adoc#simple-sharing-artifacts-between-projects, simple version>> of sharing information across project boundaries, by explicitly specifying which producer project's _consumable configuration_ to use for a locally available artifact.

[source,kotlin]
----
abstract class CreateFileTask : DefaultTask() { }
----

This simple task adds a file to our application’s root directory.

=== 2. Use Lazy Configuration
Gradle has a concept called _lazy configuration_, which allows task inputs and outputs to be referenced before they are actually set.
This is done via the link:{javadocPath}/org/gradle/api/provider/Property.html[`Property`] class type.

[source,kotlin]
----

First, a producer needs to declare a configuration which is going to be _exposed_ to consumers.
As explained in the <<declaring_dependencies.adoc#sec:resolvable-consumable-configs, configurations chapter>>, this corresponds to a _consumable configuration_.

Let's imagine that the consumer requires _instrumented classes_ from the producer, but that this artifact is _not_ the main one.

====

[[sec:convention_plugins_vs_cross_configuration]]
== Do not use cross-project configuration

An improper way to share build logic between subprojects is _cross-project configuration_ via the link:{javadocPath}//org/gradle/api/Project.html#subprojects-groovy.lang.Closure-[`subprojects {}`] and link:{javadocPath}/org/gradle/api/Project.html#allprojects-groovy.lang.Closure-[`allprojects {}`] DSL constructs.