}
    }

    void tarTo(TestFile tarFile, boolean nativeTools, boolean readOnly) {
        //TODO: there is an inconsistency here; when using native tools the root folder is put into the TAR, but only its content is packaged by the other branch
        // for example if we put an empty folder into the TAR, then native tools will insert an entry with an empty directory, while the other branch will insert no entries

            return new DefaultExternalModuleDependency("org.scala-sbt", "compiler-interface", zincVersion);
        }
    }

    /**
     * Determines Scaladoc jar to download. Note that scaladoc for Scala 2 is packaged along the compiler
     *
     * @param scalaVersion version of scala to download the scaladoc for
     * @return scaladoc dependency to download
     */

include::sample[dir="snippets/buildCache/integration-tests/groovy",files="build.gradle[tags=integTest]"]
====

=== Archives as inputs

It is common for the integration tests to depend on your packaged application.
If this happens to be a zip or tar archive, then adding it as an input to the integration test task may lead to cache misses.

Exposing artifacts for consumption::
A plugin uses configurations to define what _artifacts_ it generates for other projects to consume. For example the project would like to publish its compiled source code packaged in the JAR file to an in-house Artifactory repository.

        fails 'greet', "--stacktrace"

        then:
        failure.assertHasErrorOutput("""      > The consumer was configured to find a library for use during runtime, compatible with Java ${JavaVersion.current().majorVersion}, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '${GradleVersion.current().version}'. There are several available matching variants of com.example:producer:1.0

     */
    int getCoreLibJarsCount() {
        69
    }

    /**
     * Change this whenever you add or remove subprojects for distribution-packaged plugins (lib/plugins).
     */
    int getPackagedPluginsJarCount() {
        80
    }

    /**
     * Change this whenever you add or remove subprojects for distribution java agents (lib/agents).
     */

== Step 1. Understanding Plugins
Plugins are the primary method to organize build logic and reuse build logic within a project.

Plugins are also used to distribute custom tasks as packaged code.

	}
}

// ErrorHandlers is a list of functions which will be invoked when a nonreturnable
// error occurs.
// TODO(lavalamp): for testability, this and the below HandleError function
// should be packaged up into a testable and reusable object.
var ErrorHandlers = []ErrorHandler{
	logError,
	func(_ context.Context, _ error, _ string, _ ...interface{}) {
		(&rudimentaryErrorBackoff{
			lastErrorTime: time.Now(),

import gradlebuild.basics.isBundleGroovy4

/**
 * This project provides the "platform" for the Gradle distribution.
 * We want the versions that are packaged in the distribution to be used everywhere (e.g. in all test scenarios)
 * Hence, we lock the versions down here for all other subprojects.
 *
 * Note:
 * We use strictly here because we do not have any better means to do this at the moment.

They are applied to a project using the `plugins {}` block.
They offer better performance and maintainability compared to script plugins or precompiled script plugins.

Precompiled Script Plugins :: Precompiled script plugins are Groovy DSL or Kotlin DSL scripts compiled and distributed as Java class files packaged in a library.