anchor.diff:  [[writing_build_scripts]]
   = Writing Build Scripts
   
  -This chapter looks at some of the details of writing a build script.
  -
  -[[sec:the_gradle_build_language]]
  -== The Gradle build language
  -
  -Gradle provides a _domain specific language_, or DSL, for describing builds. This build language is available in Groovy and Kotlin.
  -
  -A Groovy build script can contain any Groovy language element.footnote:[Any language element except for statement labels.] A Kotlin build script can contain any Kotlin language element. Gradle assumes that each build script is encoded using UTF-8.
  -
  -[[sec:project_api]]
  -== The Project API
  -
  -Build scripts describe your build by configuring _projects_. A project is an abstract concept, but you typically map a Gradle project to a software component that needs to be built, like a library or an application. Each build script you have is associated with an object of type link:{groovyDslPath}/org.gradle.api.Project.html[Project] and as the build script executes, it configures this `Project`.
  -
  -In fact, almost all top-level properties and blocks in a build script are part of the `Project` API. To demonstrate, take a look at this example build script that prints the name of its project, which is accessed via the link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.api.Project:name[Project.name] property:
  -
  -.Accessing property of the Project object
  +Use a build script to configure a _project_. Each Gradle project corresponds to a software component
  +that needs to be built, like a library or an application. Each build script is associated
  +with an object of type link:{groovyDslPath}/org.gradle.api.Project.html[Project].
  +As the build script executes, it configures this `Project`.
  +
  +[IMPORTANT]
  +.Build scripts, Settings scripts, and Init scripts
  +====
  +_Build scripts_ define `Project` objects.
  +Gradle uses other scripts as well:
  +
  +- <<build_lifecycle.adoc#sec:settings_file,Settings scripts>>
  +  define link:{groovyDslPath}/org.gradle.api.initialization.Settings.html[Settings] objects.
  +- <<init_scripts.adoc#init_scripts,Init scripts>>
  +  define link:{groovyDslPath}/org.gradle.api.invocation.Gradle.html[Gradle] objects.
  +====
  +
  +== Properties
  +
  +Almost all top-level properties and blocks in a build script are part of the `Project` API.
  +The following build script uses the link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.api.Project:name[Project.name]
  +property to print the name of the project:
  +
  +.Access a Project property
   ====
   include::sample[dir="snippets/tutorial/projectApi/groovy",files="build.gradle[tags=project-name]"]
   include::sample[dir="snippets/tutorial/projectApi/kotlin",files="build.gradle.kts[tags=project-name]"]
  
positive.code: ====
  
  [.multi-language-text.lang-groovy]
  In this example, an `ext` block adds two extra properties to the `project` object. Additionally, a property named `purpose` is added to each source set by setting `ext.purpose` to `null` (`null` is a permissible value). Once the properties have been added, they can be read and set like predefined properties.
  
  [.multi-language-text.lang-kotlin]
  In this example, two extra properties are added to the `project` object using `by extra`. Additionally, a property named `purpose` is added to each source set by setting `extra["purpose"]` to `null` (`null` is a permissible value). Once the properties have been added, they can be read and set on `extra`.
  
  By requiring special syntax for adding a property, Gradle can fail fast when an attempt is made to set a (predefined or extra) property but the property is misspelled or does not exist. Extra properties can be accessed from anywhere their owning object can be accessed, giving them a wider scope than local variables. Extra properties on a project are visible from its subprojects.
  
  For further details on extra properties and their API, see the link:{groovyDslPath}/org.gradle.api.plugins.ExtraPropertiesExtension.html[ExtraPropertiesExtension] class in the API documentation.
  
  [[sec:configuring_arbitrary_objects]]
  == Configuring arbitrary objects
  
  You can configure arbitrary objects in the following very readable way.
  
  .Configuring arbitrary objects
  ====
  include::sample[dir="snippets/tutorial/configureObject/groovy",files="build.gradle[]"]
  include::sample[dir="snippets/tutorial/configureObject/kotlin",files="build.gradle.kts[]"]
  
negative.code: ====
  
  [[sec:list_and_map_literals]]
  === List and Map Instantiation Shortcuts
  
  Groovy provides shortcuts to define `List` and `Map` instances.
  For example, consider the “`apply`” method, which accepts a map parameter.
  When you apply a plugin (`apply plugin:'java'`), you don't use a map literal.
  Plugin application uses "named parameters" instead. Named parameters and map
  literals use similar syntax, but named parameters don't use wrapping brackets.
  When you call `apply`, Groovy converts the named parameter list to a map.
  
  .List and map literals
  ====
  