include::resolution_strategy_tuning.adoc[leveloffset=+2]

== PRODUCING AND CONSUMING VARIANTS OF LIBRARIES

include::component_capabilities.adoc[leveloffset=+2]
include::feature_variants.adoc[leveloffset=+2]
include::variant_model.adoc[leveloffset=+2]
include::variant_attributes.adoc[leveloffset=+2]
include::cross_project_publications.adoc[leveloffset=+2]
include::artifact_transforms.adoc[leveloffset=+2]

== PUBLISHING LIBRARIES

This is where the <<variant_model.adoc#understanding-variant-selection,variant model>> of Gradle comes into play.

In Gradle, _producer variants_ are exposed via <<declaring_dependencies.adoc#sec:resolvable-consumable-configs,consumable configurations>>.

Gradle identifies a variant of a dependency uniquely by its set of <<variant_model.adoc#sec:abm_configuration_attributes,attributes>>.
The `java-api` variant of a dependency is the variant identified by the `org.gradle.usage` attribute with value `java-api`.

When Gradle resolves a configuration, the <<variant_model.adoc#sec:abm_configuration_attributes,attributes>> on the resolved configuration determine the _requested attributes_.

====

In this example, we use a convention plugin `myproject.xctest-conventions` to expose the test results from a project to Gradle's <<variant_model.adoc#understanding-variant-selection,variant aware dependency management engine>>.

The plugin declares a consumable `binaryTestResultsElements` configuration that represents the binary test results of the `test` task.

[[sec:variant_aware_substitutions]]
=== Substituting a dependency with another variant

Gradle's dependency management engine is <<variant_model.adoc#understanding-variant-selection,variant-aware>> meaning that for a single component, the engine may select different artifacts and transitive dependencies.

// See the License for the specific language governing permissions and
// limitations under the License.

[[variant_attributes]]
= Working with Variant Attributes

As explained in the section on <<variant_model.adoc#sec:variant-aware-matching,variant aware matching>>, attributes give semantics to variants and are used by Gradle's dependency management engine to select the best matching variant.

However, the consumer has to explicitly tell which configuration it depends on, which is something we want to avoid in _variant aware resolution_.
In fact, we also <<variant_model.adoc#understanding-variant-selection, have explained>> that it is possible for a consumer to express requirements using _attributes_ and that the producer should provide the appropriate outgoing variants using attributes too.

                        <li><a href="../userguide/feature_variants.html">Modeling Feature Variants and Optional Dependencies</a></li>
                        <li><a href="../userguide/variant_model.html">Understanding Variant Selection</a></li>
                        <li><a href="../userguide/variant_attributes.html">Declaring Variant Attributes</a></li>

[[sec:implementation-conflict]]
== Implementation conflict resolution

Gradle uses variants and capabilities to identify what a module _provides_.

This is a unique feature that deserves its <<variant_model.adoc#understanding-variant-selection,own chapter>> to understand what it means and enables.

A conflict occurs the moment two modules either:

* Attempt to select incompatible variants,
* Declare the same capability

If your build consumes modules with Ivy metadata, you might be able to activate api and implementation separation as described <<variant_model.adoc#sub:ivy-mapping-to-variants,here>> if all modules follow a certain structure.

NOTE: Separating compile and runtime scope of modules is active by default in Gradle 5.0+.