You want to share a file made by a task in one project with a task in another project.
For example, one task makes a file, and the other task reads the file and uses some information inside it.
This is one way you can share information across project boundaries. (Another way is to use extension objects.)

[NOTE]
====
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.

When the producer publishes an artifact to a repository, to retrieve that artifact you will need to use <<../userguide/cross_project_publications.adoc#variant-aware-sharing, the advanced version>> of variant aware dependency resolution.
This method will also work locally.
====

== Example

.Settings
====
include::sample[dir="kotlin",files="settings.gradle.kts[]"]
include::sample[dir="groovy",files="settings.gradle[]"]
====

.Producer's build
====
include::sample[dir="kotlin",files="producer/build.gradle.kts[]"]
include::sample[dir="groovy",files="producer/build.gradle[]"]
====

.Consumer's build
====
include::sample[dir="kotlin",files="consumer/build.gradle.kts[]"]
include::sample[dir="groovy",files="consumer/build.gradle[]"]
====

See also:

- <<../userguide/cross_project_publications.adoc#cross_project_publications, Sharing outputs between projects>>

== Anti-patterns:

[WARNING]
.Don't reference other project tasks directly
====
A frequent anti-pattern to declare cross-project dependencies is below.
This publication model is unsafe and can lead to non-reproducible and hard to parallelize builds.
By declaring a dependency in this way, the task ordering between consumers and producers is not known to Gradle at the time when it is deciding the order of tasks for a given build.
This means that potentially, consumers of the file "someOtherJar" can execute before the producer task that creates the jar!
This would lead to builds that are either totally broken, or worse, broken is a way that is subtle, flaky, and difficult to debug.
[source,groovy]
dependencies {
  // This publication model can make your build flaky and broken!
  implementation project(":other").tasks.someOtherJar
}
====
