createDirs("a", "b", "c")
        settingsFile << "include 'a', 'b', 'c'"
        setupBuildWithColorTransform {
            produceDirs()
        }
        buildFile << """
            project(':a') {
                dependencies {
                    implementation project(':b')
                    implementation project(':c')

                removed = []
                incremental = true
                registerNewOutput = false
            }
        """
        setupBuildWithColorTransform {
            produceDirs()
            params("""
                addedFiles.set(provider { added })
                modifiedFiles.set(provider { modified })
                removedFiles.set(provider { removed })

         * ${project.name}FileName - changes the name of the file to write to in the directory
         * ${project.name}Content - changes the text to write to the output file.
         */
        void produceDirs() {
            producerTaskClassName = "DirProducer"
            producerConfig = """

 * added to the task graph.  For example "clean build" on the command line implies that the user wants
 * to run the clean tasks of each project before the build tasks of each project.  Ordinal nodes ensure
 * this order by tracking the dependencies of destroyers and producers in each group of tasks added to

    @Override
    public ValueProducer getProducer() {
        ImmutableList.Builder<ValueProducer> producers = ImmutableList.builderWithExpectedSize(items.size());
        for (Provider<R> item : items) {
            producers.add(Providers.internal(item).getProducer());
        }
        return new MergeValueProducer(producers.build());
    }

    private static class MergeValueProducer implements ValueProducer {

[[sec:understanding-diff-libraries-and-apps]]
= Understanding the difference between libraries and applications

[[sub:producers-vs-consumers]]
== Producers vs consumers

A key concept in dependency management with Gradle is the difference between consumers and producers.

When you _build_ a library, you are effectively on the _producer_ side: you are producing _artifacts_ which are going to be _consumed_ by someone else, the _consumer_.

            );
        }
    }

    private void collectValidationProblemsForConsumer(LocalTaskNode consumer, TypeValidationContext validationContext, String locationConsumedByThisTask, Collection<Node> producers) {
        producers.stream()
            .filter(producerNode -> hasNoSpecifiedOrder(producerNode, consumer))
            .filter(MissingTaskDependencyDetector::isEnabled)

 * automate the process, often adding features like monitoring, debugging, and cancellation.
 * Examples of frameworks include:
 *
 * <ul>
 *   <li><a href="https://dagger.dev/producers.html">Dagger Producers</a>
 * </ul>
 *
 * <p>The main purpose of {@link #addListener addListener} is to support this chaining. You will
 * rarely use it directly, in part because it does not provide direct access to the {@code Future}

 * automate the process, often adding features like monitoring, debugging, and cancellation.
 * Examples of frameworks include:
 *
 * <ul>
 *   <li><a href="https://dagger.dev/producers.html">Dagger Producers</a>
 * </ul>
 *
 * <p>The main purpose of {@link #addListener addListener} is to support this chaining. You will
 * rarely use it directly, in part because it does not provide direct access to the {@code Future}

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!