anchor.diff:  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.
  +You may notice that there are two code snippets referencing the “`hello`” task. The first one, which uses the “`task`” keyword (in Groovy) or the `task()` function (in Kotlin), constructs the task and provides it's base configuration. The second piece doesn't use the “`task`” keyword or function, 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
  
positive.code: include::sample[dir="userguide/multiproject/dependencies/java/kotlin",files="settings.gradle.kts[];build.gradle.kts[]"]
  ====
  
  All the build logic is in the “`build.gradle`” file 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:
  
  
negative.code: 
  In order to make good use of cross project configuration without running into issues for parallel and 'configuration on demand' options, follow these recommendations:
  
  * Avoid a subproject's build script referencing other subprojects; preferring cross configuration from the root project.
  * Avoid changing the configuration of other projects at execution time.
  
  
  