Often enterprises want to standardize the build platform for all projects in the organization by defining common conventions or rules.
You can achieve that with the help of initialization scripts.
<<init_scripts.adoc#init_scripts,Initialization scripts>> make it extremely easy to apply build logic across all projects on a single machine.
For example, to declare a in-house repository and its credentials.

        """)

        def initScript = file('init-script.gradle') << """
            initscript {
                dependencies {
                    classpath(files("$pluginJar"))
                }
            }

            apply plugin: MyInitPluginPlugin
        """

        when:
        executer.usingInitScript(initScript)

        then:
        succeeds("help")

private
fun KotlinLexer.packageDefinitionFound() = tokenType == KtTokens.PACKAGE_KEYWORD


private
val packageParsingAbortIdentifiers = setOf("import", "buildscript", "plugins", "pluginManagement", "initscript")


private
fun KotlinLexer.tooLateForPackageStatement(): Boolean {
    // based on https://kotlinlang.org/docs/reference/grammar.html#script

        notifications.op(RunRequestedWorkBuildOperationType.Details).parentId == notifications.op(RunBuildBuildOperationType.Details).id
    }

    def "emits for GradleBuild tasks"() {
        when:
        def initScript = file("init.gradle") << """
            if (parent == null) {
                ${notifications.registerListener()}
            }
        """
        settingsFile << "rootProject.name = 'parent'"

include::working_with_files.adoc[leveloffset=+2]
include::logging.adoc[leveloffset=+2]
include::potential_traps.adoc[leveloffset=+2]
include::build_environment.adoc[leveloffset=+2]
include::init_scripts.adoc[leveloffset=+2]
include::custom_gradle_types.adoc[leveloffset=+2]
include::build_services.adoc[leveloffset=+2]
include::dataflow_actions.adoc[leveloffset=+2]
include::test_kit.adoc[leveloffset=+2]

                                update(it.toString().toByteArray())
                            }
                        updateWith("pluginManagement")
                        updateWith("initscript")
                        updateWith("buildscript")
                        updateWith("plugins")
                    }
                    digest()
                }
        }
    }
}

====

*Example 4:* Setting Gradle properties from the command line:
====
----
$ gradle -DgradlePropertiesProp=commandLineValue
----
====

Note that <<init_scripts.adoc#init_scripts, initialization scripts>> can't read Gradle properties directly.
The earliest Gradle properties can be read in initialization scripts is on `settingsEvaluated {}`:

    def "emits deprecation warnings as build operation progress events with context"() {
        when:
        settingsFile "rootProject.name = 'root'"

        initScript  """
            org.gradle.internal.deprecation.DeprecationLogger.deprecate('Init script')
                .willBeRemovedInGradle9()
                .undocumented()
                .nagUser()

include::sample[dir="snippets/plugins/pluginManagement/kotlin", files="settings.gradle.kts[]"]
include::sample[dir="snippets/plugins/pluginManagement/groovy", files="settings.gradle[]"]
====

The block can also be used in <<init_scripts.adoc#init_scripts,Initialization Script>>:

====
include::sample[dir="snippets/plugins/pluginManagement/kotlin", files="init.gradle.kts[]"]
include::sample[dir="snippets/plugins/pluginManagement/groovy", files="init.gradle[]"]

On top of that, apply the following conventions for better IDE support:

* Name scripts that are applied to `Settings` according to the pattern `*.settings.gradle.kts`,
* Name <<init_scripts.adoc#init_scripts,init scripts>> according to the pattern `*.init.gradle.kts`.


== Applying plugins

Just like with the Groovy DSL, there are two ways to apply Gradle plugins: