anchor.diff:  // === `Property`, `Provider` and `NamedDomainObjectProvider`
   
   
  -[[sec::multi_project_builds]]
  -== Multi-project builds
  -
  -To get the most benefits of the Gradle Kotlin DSL you should strive to keep your build scripts declarative.
  -The main thing to remember here is that in order to get type-safe accessors, plugins must be applied before the body of build scripts.
  -
  -As seen above, this can be achieved by using the `plugins {}` block.
  -In multi-project builds you should centrally declare plugin dependencies in the root project build file, specifying the version, without applying those used in sub-projects.
  -Then simply apply them by ID in sub projects build scripts.
  -
  -.Declare plugin dependencies in the root build script
  -====
  -include::sample[dir="kotlinDsl/multiProjectBuild",files="settings.gradle.kts[tags=base];build.gradle.kts[tags=root];domain/build.gradle.kts[];infra/build.gradle.kts[];http/build.gradle.kts[]"]
  -====
  -
  -[CAUTION]
  -.Configuration on demand
  ---
  -Enabling the incubating <<multi_project_builds#sec:configuration_on_demand,configuration on demand>> feature is not recommended as it can lead to very hard-to-diagnose problems.
  -The strictness of the Gradle Kotlin DSL makes it even more likely that problems will arise.
  -In order to save you trouble, you should disable it if it's already enabled.
  -
  -The same is true for `evaluationDependsOn(projectPath)` and `evaluationDependsOnChildren()`.
  -Favor <<multi_project_builds#sec:decoupled_projects,decoupling your projects>> instead.
  -
  -// TODO note that these will be deprecated soon, for Gradle 5?, need an issue link
  ---
  -
  -If your build requires additional plugin repositories, they should be declared in the `pluginManagement {}` block in your `settings.gradle.kts` file:
  -
  -.Declare additional plugin repositories
  -====
  -include::sample[dir="kotlinDsl/multiProjectBuild",files="settings.gradle.kts[tags=repositories]"]
  -====
  -
  -=== Cross-configuring projects
  -
  -You might want to cross-configure projects, for example configuring sub projects from the root project build script.
  -In that case you won't have the help of the type-safe accessors for model elements contributed by the plugins and have to rely on string literals and the API.
  -
  -For the sake of the example, let's look at the same build as above but fully configured from the root build script:
  -
  -.Cross-configuring projects
  -====
  -include::sample[dir="kotlinDsl/multiProjectBuild",files="settings.gradle.kts[tags=base];build.gradle.kts[tags=cross]"]
  -====
  -
  -It's more verbose and requires more gymnastic to write but it works and can be useful.
  -See the <<sec:configuring_plugins>> section above for a detailed explanation.
  -
  -=== Plugins not available using the `plugins {}` block
  -
  -Plugins fetched from a source other than the link:https://plugins.gradle.org/[Gradle Plugin Portal] may or may not be usable with the plugins {} block.
  -It depends on how they have been published.
  -
  -For example, the Android Plugin for Gradle is not published to the Gradle Plugin Portal and at least up to version 3.2.0 of the plugin, the metadata required to resolve the artifacts for a given plugin identifier is not published to the Google repository.
  -
  -Because of this, projects typically apply the plugin via a `buildscript {}` block and the imperative `apply()` function.
  -However, you can use the `plugins {}` block if you configure your build appropriately.
  -We will show you in this section how to do that for the Android Plugin for Gradle.
  -
  -[NOTE]
  -When publishing plugins, please use Gradle's built-in <<java_gradle_plugin#, Java Gradle Plugin>> Plugin. It automates the publication of the metadata necessary to make your plugins usable with the `plugins {}` block.
  -
  -The goal is to instruct your build on how to map the `com.android.application` plugin identifier to a resolvable artifact.
  -This is done in two steps:
  -
  -* Add a plugin repository to the build's settings file
  -* Map the plugin ID to the corresponding artifact coordinates
  -
  -This is done in the settings file within the `pluginManagement {}` block.
  -The following sample maps the `com.android.application` ID to the `com.android.tools.build:gradle:<version>` artifact available in the `google()` repository:
  -
  -.Mapping plugin IDs to dependency coordinates
  -====
  -include::sample[dir="kotlinDsl/androidBuild",files="settings.gradle.kts[tags=android];build.gradle.kts[tags=android];lib/build.gradle.kts[tags=android];app/build.gradle.kts[tags=android]"]
  -====
  -
  -See the <<plugins#sec:plugin_management, Plugin Management>> section of the Gradle user manual for more information.
  -
  -The same approach can be used to resolve plugins from composite builds, which link:https://github.com/gradle/gradle/issues/2528[do not expose plugin markers] yet.
  -Simply map the plugin ID to the corresponding artifact coordinates as shown in the Android samples above.
  -
  -
   [[sec:kotlin-dsl_plugin]]
   == The `kotlin-dsl` plugin
   
  
positive.code: ====
  
  
  [[sec:containers]]
  == Working with containers
  
  
negative.code: 
  === Extra properties
  
  // TODO demonstrate how to cross project borders
  
  Extra properties are documented in the <<writing_build_scripts#sec:extra_properties, Writing Build Scripts>> chapter.
  
  On every `ExtensionAware` type they can be used via the `extra` property as a Kotlin delegated property, see the sample below.
  