Laura Kassovic <******@****.***> 1701107622 -0800

Combined with <<publishing_maven.adoc#publishing_maven:resolved_dependencies,publishing resolved versions>>, you can also replace the declared dynamic version part at publication time.
Consumers will instead see the versions that your release resolved.

Locking is enabled per <<declaring_dependencies.adoc#sec:what-are-dependency-configurations,dependency configuration>>.

A <<dynamic_versions.adoc#sub:declaring_dependency_with_dynamic_version,dynamic version>> can be either a version range (e.g. `2.+`) or it can be a placeholder for the latest version available e.g. `latest.integration`.

Alternatively, the module you request can change over time even for the same version, a so-called <<dynamic_versions.adoc#sub:declaring_dependency_with_changing_version,changing version>>.

- <<dependency_capability_conflict.adoc#sec:handling-mutually-exclusive-deps,Resolving mutually exclusive dependency conflicts>>:
  Another situation that you often see solved by excludes is that two dependencies cannot be used together because they represent two implementations of the same thing (the same <<dependency_capability_conflict.adoc#sub:capabilities,capability>>).

This is a direct consequence of the transitivity of <<dependency_constraints.adoc#sec:adding-constraints-transitive-deps, dependency constraints>>.
So if you have a multi-project build, and you wish that consumers get the same version of all your modules, Gradle provides a simple way to do this using the <<java_platform_plugin.adoc#java_platform_plugin,Java Platform Plugin>>.

For example, if you have a project that consists of 3 modules:

A published Ivy module can be consumed by Gradle (see <<declaring_dependencies.adoc#declaring-dependencies,Declaring Dependencies>>) and other tools that understand the Ivy format. You can learn about the fundamentals of publishing in <<publishing_setup.adoc#publishing_overview,Publishing Overview>>.

[[publishing_ivy:usage]]
== Usage

As of Gradle 6.0, the <<publishing_gradle_module_metadata.adoc#sec:understanding-gradle-module-md,Gradle Module Metadata>> will always be published alongside the Ivy XML or Maven POM metadata file.

Gradle makes it easy to publish to these types of repository by providing some prepackaged infrastructure in the form of the <<publishing_maven.adoc#publishing_maven,Maven Publish Plugin>> and the <<publishing_ivy.adoc#publishing_ivy,Ivy Publish Plugin>>.

publishing artifacts, you often want to sign them so the consumer of your artifacts can verify their signature. For example, the <<java_plugin.adoc#java_plugin,Java plugin>> defines a component that you can use to define a publication to a Maven (or Ivy) repository using the <<publishing_maven.adoc#publishing_maven, Maven Publish Plugin>> (or the <<publishing_ivy.adoc#publishing_ivy, Ivy Publish Plugin>>, respectively). Using the Signing DSL, you can specify that all of the artifacts of this publication...

This task is added by the <<base_plugin.adoc#base_plugin,Base Plugin>>.

`check` - Task (lifecycle)::
Aggregate task that performs verification tasks, such as running the tests.
Some plugins add their own verification task to `check`.
 For example, the <<xctest_plugin.adoc#xctest_plugin,XCTest Plugin>> attach its test task to this lifecycle task.
This task is added by the <<base_plugin.adoc#base_plugin,Base Plugin>>.

| Generates minimal solution file.

| <<cpp_application_plugin.adoc#cpp_application_plugin,{cpp} Application>>
| Adds a target representing the {cpp} application to the project file.

| <<cpp_library_plugin.adoc#cpp_library_plugin,{cpp} Library>>
| Adds a target for each specified linkage representing the shared and/or static library to the project file.

| <<swift_application_plugin.adoc#swift_application_plugin,Swift Application>>