// Copyright 2018 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[customizing_dependency_resolution_behavior]]
== Customizing Dependency Resolution Behavior

There are a number of ways that you can influence how Gradle resolves dependencies. All of these mechanisms offer an API to define a reason for why they are used. Providing reasons makes dependency resolution results more understandable. If any customization influenced the resolution result, the provided reason will show up in <<sec:identifying_reason_dependency_selection,dependency insight>> report.

[[sec:dependency_resolve_rules]]
=== Using dependency resolve rules

A dependency resolve rule is executed for each resolved dependency, and offers a powerful api for manipulating a requested dependency prior to that dependency being resolved. The feature currently offers the ability to change the group, name and/or version of a requested dependency, allowing a dependency to be substituted with a completely different module during resolution.

Dependency resolve rules provide a very powerful way to control the dependency resolution process, and can be used to implement all sorts of advanced patterns in dependency management. Some of these patterns are outlined below. For more information and code samples see the api:org.gradle.api.artifacts.ResolutionStrategy[] class in the API documentation.

[[sec:releasable_unit]]
==== Modelling releasable units

Often an organisation publishes a set of libraries with a single version; where the libraries are built, tested and published together. These libraries form a "releasable unit", designed and intended to be used as a whole. It does not make sense to use libraries from different releasable units together.

But it is easy for transitive dependency resolution to violate this contract. For example:

* `module-a` depends on `releasable-unit:part-one:1.0`
* `module-b` depends on `releasable-unit:part-two:1.1`

A build depending on both `module-a` and `module-b` will obtain different versions of libraries within the releasable unit.

Dependency resolve rules give you the power to enforce releasable units in your build. Imagine a releasable unit defined by all libraries that have `org.gradle` group. We can force all of these libraries to use a consistent version:
++++
<sample id="releasable-unit" dir="userguide/dependencyManagement/customizingResolution/resolutionStrategy" title="Forcing a consistent version for a group of libraries">
    <sourcefile file="build.gradle" snippet="releasable-unit"/>
</sample>
++++

[[sec:custom_versioning_scheme]]
==== Implementing a custom versioning scheme

In some corporate environments, the list of module versions that can be declared in Gradle builds is maintained and audited externally. Dependency resolve rules provide a neat implementation of this pattern:

* In the build script, the developer declares dependencies with the module group and name, but uses a placeholder version, for example: `default`.
* The `default` version is resolved to a specific version via a dependency resolve rule, which looks up the version in a corporate catalog of approved modules.

This rule implementation can be neatly encapsulated in a corporate plugin, and shared across all builds within the organisation.
++++
<sample id="custom-versioning-scheme" dir="userguide/dependencyManagement/customizingResolution/resolutionStrategy" title="Using a custom versioning scheme">
    <sourcefile file="build.gradle" snippet="custom-versioning-scheme"/>
</sample>
++++

[[sec:blacklisting_version]]
==== Blacklisting a particular version with a replacement

Dependency resolve rules provide a mechanism for blacklisting a particular version of a dependency and providing a replacement version. This can be useful if a certain dependency version is broken and should not be used, where a dependency resolve rule causes this version to be replaced with a known good version. One example of a broken module is one that declares a dependency on a library that cannot be found in any of the public repositories, but there are many other reasons why a particular module version is unwanted and a different version is preferred.

In example below, imagine that version `1.2.1` contains important fixes and should always be used in preference to `1.2`. The rule provided will enforce just this: any time version `1.2` is encountered it will be replaced with `1.2.1`. Note that this is different from a forced version as described above, in that any other versions of this module would not be affected. This means that the 'newest' conflict resolution strategy would still select version `1.3` if this version was also pulled transitively.

++++
<sample id="blacklisting_version" dir="userguide/dependencyManagement/customizingResolution/resolutionStrategy" title="Blacklisting a version with a replacement">
    <sourcefile file="build.gradle" snippet="blacklisting_version"/>
</sample>
++++

[[sec:module_substitution]]
==== Substituting a dependency module with a compatible replacement

At times a completely different module can serve as a replacement for a requested module dependency. Examples include using `groovy` in place of `groovy-all`, or using `log4j-over-slf4j` instead of `log4j`. You can perform these substitutions using dependency resolve rules:

++++
<sample id="module_substitution" dir="userguide/dependencyManagement/customizingResolution/resolutionStrategy" title="Changing dependency group and/or name during resolution">
    <sourcefile file="build.gradle" snippet="module_substitution"/>
</sample>
++++

[[sec:dependency_substitution_rules]]
=== Using dependency substitution rules

Dependency substitution rules work similarly to dependency resolve rules. In fact, many capabilities of dependency resolve rules can be implemented with dependency substitution rules. They allow project and module dependencies to be transparently substituted with specified replacements. Unlike dependency resolve rules, dependency substitution rules allow project and module dependencies to be substituted interchangeably.

_Adding a dependency substitution rule to a configuration changes the timing of when that configuration is resolved._ Instead of being resolved on first use, the configuration is instead resolved when the task graph is being constructed. This can have unexpected consequences if the configuration is being further modified during task execution, or if the configuration relies on modules that are published during execution of another task.

To explain:

* A `Configuration` can be declared as an input to any Task, and that configuration can include project dependencies when it is resolved.
* If a project dependency is an input to a Task (via a configuration), then tasks to build the project artifacts must be added to the task dependencies.
* In order to determine the project dependencies that are inputs to a task, Gradle needs to resolve the `Configuration` inputs.
* Because the Gradle task graph is fixed once task execution has commenced, Gradle needs to perform this resolution prior to executing any tasks.

In the absence of dependency substitution rules, Gradle knows that an external module dependency will never transitively reference a project dependency. This makes it easy to determine the full set of project dependencies for a configuration through simple graph traversal. With this functionality, Gradle can no longer make this assumption, and must perform a full resolve in order to determine the project dependencies.

[[sec:module_to_project_substitution]]
==== Substituting an external module dependency with a project dependency

One use case for dependency substitution is to use a locally developed version of a module in place of one that is downloaded from an external repository. This could be useful for testing a local, patched version of a dependency.

The module to be replaced can be declared with or without a version specified.

++++
<sample id="module_to_project_substitution" dir="userguide/dependencyManagement/customizingResolution/substitutionRule" title="Substituting a module with a project">
    <sourcefile file="build.gradle" snippet="module_to_project_substitution"/>
</sample>
++++

Note that a project that is substituted must be included in the multi-project build (via `settings.gradle`). Dependency substitution rules take care of replacing the module dependency with the project dependency and wiring up any task dependencies, but do not implicitly include the project in the build.

[[sec:project_to_module_substitution]]
==== Substituting a project dependency with a module replacement

Another way to use substitution rules is to replace a project dependency with a module in a multi-project build. This can be useful to speed up development with a large multi-project build, by allowing a subset of the project dependencies to be downloaded from a repository rather than being built.

The module to be used as a replacement must be declared with a version specified.

++++
<sample id="project_to_module_substitution" dir="userguide/dependencyManagement/customizingResolution/substitutionRule" title="Substituting a project with a module">
    <sourcefile file="build.gradle" snippet="project_to_module_substitution"/>
</sample>
++++

When a project dependency has been replaced with a module dependency, that project is still included in the overall multi-project build. However, tasks to build the replaced dependency will not be executed in order to build the resolve the depending `Configuration`.

[[sec:conditional_dependency_substitution]]
==== Conditionally substituting a dependency

A common use case for dependency substitution is to allow more flexible assembly of sub-projects within a multi-project build. This can be useful for developing a local, patched version of an external dependency or for building a subset of the modules within a large multi-project build.

The following example uses a dependency substitution rule to replace any module dependency with the group `org.example`, but only if a local project matching the dependency name can be located.

++++
<sample id="project_substitution" dir="userguide/dependencyManagement/customizingResolution/conditionalSubstitutionRule" title="Conditionally substituting a dependency">
    <sourcefile file="build.gradle" snippet="project_substitution"/>
</sample>
++++

Note that a project that is substituted must be included in the multi-project build (via `settings.gradle`). Dependency substitution rules take care of replacing the module dependency with the project dependency, but do not implicitly include the project in the build

[[sec:component_metadata_rules]]
=== Using component metadata rules

Each module has metadata associated with it, such as its group, name, version, dependencies, and so on. This metadata typically originates in the module's descriptor. Metadata rules allow certain parts of a module's metadata to be manipulated from within the build script. They take effect after a module's descriptor has been downloaded, but before it has been selected among all candidate versions. This makes metadata rules another instrument for customizing dependency resolution.

One piece of module metadata that Gradle understands is a module's _status scheme_. This concept, also known from Ivy, models the different levels of maturity that a module transitions through over time. The default status scheme, ordered from least to most mature status, is `integration`, `milestone`, `release`. Apart from a status scheme, a module also has a (current) _status_, which must be one of the values in its status scheme. If not specified in the (Ivy) descriptor, the status defaults to `integration` for Ivy modules and Maven snapshot modules, and `release` for Maven modules that aren't snapshots.

A module's status and status scheme are taken into consideration when a `latest` version selector is resolved. Specifically, `latest.someStatus` will resolve to the highest module version that has status `someStatus` or a more mature status. For example, with the default status scheme in place, `latest.integration` will select the highest module version regardless of its status (because `integration` is the least mature status), whereas `latest.release` will select the highest module version with status `release`. Here is what this looks like in code:

++++
<sample id="latestSelector" dir="userguide/dependencyManagement/customizingResolution/metadataRule" title="'Latest' version selector">
    <sourcefile file="build.gradle" snippet="latest-selector"/>
    <output args="-q listConfigs"/>
</sample>
++++

The next example demonstrates `latest` selectors based on a custom status scheme declared in a component metadata rule that applies to all modules:

++++
<sample id="customStatusScheme" dir="userguide/dependencyManagement/customizingResolution/metadataRule" title="Custom status scheme">
    <sourcefile file="build.gradle" snippet="custom-status-scheme"/>
</sample>
++++

Component metadata rules can be applied to a specified module. Modules must be specified in the form of `group:module`.

++++
<sample id="customStatusSchemeModule" dir="userguide/dependencyManagement/customizingResolution/metadataRule" title="Custom status scheme by module">
    <sourcefile file="build.gradle" snippet="custom-status-scheme-module"/>
</sample>
++++

Gradle can also create component metadata rules utilizing Ivy-specific metadata for modules resolved from an Ivy repository. Values from the Ivy descriptor are made available via the api:org.gradle.api.artifacts.ivy.IvyModuleDescriptor[] interface.

++++
<sample id="ivyComponentMetadataRule" dir="userguide/dependencyManagement/customizingResolution/metadataRule" title="Ivy component metadata rule">
    <sourcefile file="build.gradle" snippet="ivy-component-metadata-rule"/>
</sample>
++++

Note that any rule that declares specific arguments must _always_ include a api:org.gradle.api.artifacts.ComponentMetadataDetails[] argument as the first argument. The second Ivy metadata argument is optional.

Component metadata rules can also be defined using a _rule source_ object. A rule source object is any object that contains exactly one method that defines the rule action and is annotated with `@Mutate`.

This method:

* must return void.
* must have api:org.gradle.api.artifacts.ComponentMetadataDetails[] as the first argument.
* may have an additional parameter of type api:org.gradle.api.artifacts.ivy.IvyModuleDescriptor[].

++++
<sample id="ruleSourceComponentMetadataRule" dir="userguide/dependencyManagement/customizingResolution/metadataRule" title="Rule source component metadata rule">
    <sourcefile file="build.gradle" snippet="rule-source-component-metadata-rule"/>
</sample>
++++

[[sec:component_selection_rules]]
=== Using component selection rules

Component selection rules may influence which component instance should be selected when multiple versions are available that match a version selector. Rules are applied against every available version and allow the version to be explicitly rejected by rule. This allows Gradle to ignore any component instance that does not satisfy conditions set by the rule. Examples include:

* For a dynamic version like `1.+` certain versions may be explicitly rejected from selection.
* For a static version like `1.4` an instance may be rejected based on extra component metadata such as the Ivy branch attribute, allowing an instance from a subsequent repository to be used.

Rules are configured via the api:org.gradle.api.artifacts.ComponentSelectionRules[] object. Each rule configured will be called with a api:org.gradle.api.artifacts.ComponentSelection[] object as an argument which contains information about the candidate version being considered. Calling api:org.gradle.api.artifacts.ComponentSelection#reject[] causes the given candidate version to be explicitly rejected, in which case the candidate will not be considered for the selector.

The following example shows a rule that disallows a particular version of a module but allows the dynamic version to choose the next best candidate.

++++
<sample id="componentSelectionRulesReject" dir="userguide/dependencyManagement/customizingResolution/selectionRule" title="Component selection rule">
    <sourcefile file="build.gradle" snippet="reject-version-1.1"/>
</sample>
++++

Note that version selection is applied starting with the highest version first. The version selected will be the first version found that all component selection rules accept. A version is considered accepted if no rule explicitly rejects it.

Similarly, rules can be targeted at specific modules. Modules must be specified in the form of `group:module`.

++++
<sample id="componentSelectionRulesTarget" dir="userguide/dependencyManagement/customizingResolution/selectionRule" title="Component selection rule with module target">
    <sourcefile file="build.gradle" snippet="targeted-component-selection"/>
</sample>
++++

Component selection rules can also consider component metadata when selecting a version. Possible metadata arguments that can be considered are api:org.gradle.api.artifacts.ComponentMetadata[] and api:org.gradle.api.artifacts.ivy.IvyModuleDescriptor[].

++++
<sample id="componentSelectionRulesMetadata" dir="userguide/dependencyManagement/customizingResolution/selectionRule" title="Component selection rule with metadata">
    <sourcefile file="build.gradle" snippet="component-selection-with-metadata"/>
</sample>
++++

Note that a api:org.gradle.api.artifacts.ComponentSelection[] argument is _always_ required as the first parameter when declaring a component selection rule with additional Ivy metadata parameters, but the metadata parameters can be declared in any order.

Lastly, component selection rules can also be defined using a _rule source_ object. A rule source object is any object that contains exactly one method that defines the rule action and is annotated with `@Mutate`.

This method:

* must return void.
* must have api:org.gradle.api.artifacts.ComponentSelection[] as the first argument.
* may have additional parameters of type api:org.gradle.api.artifacts.ComponentMetadata[] and/or api:org.gradle.api.artifacts.ivy.IvyModuleDescriptor[].

++++
<sample id="componentSelectionRulesRuleSource" dir="userguide/dependencyManagement/customizingResolution/selectionRule" title="Component selection rule using a rule source object">
    <sourcefile file="build.gradle" snippet="api-component-selection"/>
</sample>
++++

[[sec:module_replacement]]
=== Using module replacement rules

Module replacement rules allow a build to declare that a legacy library has been replaced by a new one. A good example when a new library replaced a legacy one is the `google-collections` -&gt; `guava` migration. The team that created google-collections decided to change the module name from `com.google.collections:google-collections` into `com.google.guava:guava`. This is a legal scenario in the industry: teams need to be able to change the names of products they maintain, including the module coordinates. Renaming of the module coordinates has impact on conflict resolution.

To explain the impact on conflict resolution, let's consider the `google-collections` -&gt; `guava` scenario. It may happen that both libraries are pulled into the same dependency graph. For example, _our project_ depends on `guava` but some of _our dependencies_ pull in a legacy version of `google-collections`. This can cause runtime errors, for example during test or application execution. Gradle does not automatically resolve the `google-collections` -&gt; `guava` conflict because it is not considered as a _version conflict_. It's because the module coordinates for both libraries are completely different and conflict resolution is activated when `group` and `module` coordinates are the same but there are different versions available in the dependency graph (for more info, refer to the section on conflict resolution). Traditional remedies to this problem are:

* Declare exclusion rule to avoid pulling in `google-collections` to graph. It is probably the most popular approach.
* Avoid dependencies that pull in legacy libraries.
* Upgrade the dependency version if the new version no longer pulls in a legacy library.
* Downgrade to `google-collections`. It's not recommended, just mentioned for completeness.

Traditional approaches work but they are not general enough. For example, an organisation wants to resolve the `google-collections` -&gt; `guava` conflict resolution problem in all projects. Starting from Gradle 2.2 it is possible to declare that certain module was replaced by other. This enables organisations to include the information about module replacement in the corporate plugin suite and resolve the problem holistically for all Gradle-powered projects in the enterprise.

++++
<sample id="module_replacement_declaration" dir="userguide/dependencyManagement/customizingResolution/replacementRule" title="Declaring a module replacement">
    <sourcefile file="build.gradle" snippet="module_replacement_declaration"/>
</sample>
++++

For more examples and detailed API, refer to the DSL reference for api:org.gradle.api.artifacts.dsl.ComponentMetadataHandler[].

What happens when we declare that `google-collections` is replaced by `guava`? Gradle can use this information for conflict resolution. Gradle will consider every version of `guava` newer/better than any version of `google-collections`. Also, Gradle will ensure that only guava jar is present in the classpath / resolved file list. Note that if only `google-collections` appears in the dependency graph (e.g. no `guava`) Gradle will not eagerly replace it with `guava`. Module replacement is an information that Gradle uses for resolving conflicts. If there is no conflict (e.g. only `google-collections` or only `guava` in the graph) the replacement information is not used.

Currently it is not possible to declare that a given module is replaced by a set of modules. However, it is possible to declare that multiple modules are replaced by a single module.

[[sec:configuration_defaults]]
=== Specifying default dependencies for a configuration

A configuration can be configured with default dependencies to be used if no dependencies are explicitly set for the configuration. A primary use case of this functionality is for developing plugins that make use of versioned tools that the user might override. By specifying default dependencies, the plugin can use a default version of the tool only if the user has not specified a particular version to use.

++++
<sample id="configuration_default_dependencies" dir="userguide/dependencyManagement/customizingResolution/defaultDependency" title="Specifying default dependencies on a configuration">
    <sourcefile file="build.gradle" snippet="configuration-default-dependencies"/>
</sample>
++++

[[sec:ivy_dynamic_resolve_mode]]
=== Enabling Ivy dynamic resolve mode

Gradle's Ivy repository implementations support the equivalent to Ivy's dynamic resolve mode. Normally, Gradle will use the `rev` attribute for each dependency definition included in an `ivy.xml` file. In dynamic resolve mode, Gradle will instead prefer the `revConstraint` attribute over the `rev` attribute for a given dependency definition. If the `revConstraint` attribute is not present, the `rev` attribute is used instead.

To enable dynamic resolve mode, you need to set the appropriate option on the repository definition. A couple of examples are shown below. Note that dynamic resolve mode is only available for Gradle's Ivy repositories. It is not available for Maven repositories, or custom Ivy `DependencyResolver` implementations.

++++
<sample id="dynamicResolveMode" dir="userguide/dependencyManagement/customizingResolution/ivyDynamicMode" title="Enabling dynamic resolve mode">
    <sourcefile file="build.gradle" snippet="ivy-repo-dynamic-mode"/>
</sample>
++++
