anchor.diff:  include::{samplesPath}/userguide/multiproject/addKrill/water/multiprojectAddKrill.out[]
   ----
   
  -Is this cool or is this cool? And how does this work? The Project API provides a property `allprojects` which returns a list with the current project and all its subprojects underneath it. If you call `allprojects` with a closure, the statements of the closure are delegated to the projects associated with `allprojects`. You could also do an iteration via `allprojects.each`, but that would be more verbose.
  +Is this cool or is this cool? And how does this work? The Project API provides a property `allprojects` which returns a list with the current project and all its subprojects underneath it. If you call `allprojects` with a closure, the statements of the closure are delegated to the projects associated with `allprojects`. You could also do an iteration via `allprojects.each` (in Groovy) or `allprojects.forEach` (in Kotlin), but that would be more verbose.
   
   Other build systems use inheritance as the primary means for defining common behavior. We also offer inheritance for projects as you will see later. But Gradle uses configuration injection as the usual way of defining common behavior. We think it provides a very powerful and flexible way of configuring multiproject builds.
   
  
positive.code: include::{samplesPath}/userguide/multiproject/useSubprojects/water/multiprojectUseSubprojects.out[]
  ----
  
  You may notice that there are two code snippets referencing the “`hello`” task. The first one, which uses the “`task`” keyword, constructs the task and provides it's base configuration. The second piece doesn't use the “`task`” keyword, as it is further configuring the existing “`hello`” task. You may only construct a task once in a project, but you may add any number of code blocks providing additional configuration.
  
  [[sub:adding_specific_behavior]]
  === Adding specific behavior
  
negative.code: include::sample[dir="userguide/multiproject/dependencies/java/kotlin",files="settings.gradle.kts[];build.gradle.kts[]"]
  ====
  
  All the build logic is in the build script of the root project.footnote:[We do this here, as it makes the layout a bit easier. We usually put the project specific stuff into the build script of the respective projects.] A “_lib_” dependency is a special form of an execution dependency. It causes the other project to be built first and adds the jar with the classes of the other project to the classpath. It also adds the dependencies of the other project to the classpath. So you can enter the “`api`” directory and trigger a “`gradle compile`”. First the “`shared`” project is built and then the “`api`” project is built. Project dependencies enable partial multi-project builds.
  
  If you come from Maven land you might be perfectly happy with this. If you come from Ivy land, you might expect some more fine grained control. Gradle offers this to you:
  
  