anchor.diff:  
   Using the project name for filtering is one option. Using <<writing_build_scripts.adoc#sec:extra_properties,extra project properties>> is another.
   
  -=== Example: Adding custom behaviour to some projects (filtered by project properties)
  -
  -.Project layout
  +.Adding custom behaviour to some projects (filtered by project properties)
  +====
  +[.multi-language-sample]
  +=====
  +.Project layout
  +[source, groovy]
   ----
   .
   ├── bluewhale
  
positive.code: 
  When we executed the `hello` task from the root project dir, things behaved in an intuitive way. All the `hello` tasks of the different projects were executed. Let's switch to the `bluewhale` dir and see what happens if we execute Gradle from there.
  
  === Example: Running build from subproject
  
  [source.multi-language-sample,groovy]
  ----
  > gradle -q hello --settings-file=../settings.gradle
  include::{samplesPath}/userguide/multiproject/tropicalWithProperties/water/multiprojectSubBuild.out[]
  ----
  [source.multi-language-sample,kotlin]
  ----
  > gradle -q hello --settings-file=../settings.gradle.kts
  include::{samplesPath}/userguide/multiproject/tropicalWithProperties/water/multiprojectSubBuild.out[]
  ----
  
  The basic rule behind Gradle's behavior is simple. Gradle looks down the hierarchy, starting with the _current dir_, for tasks with the name `hello` and executes them. One thing is very important to note. Gradle _always_ evaluates _every_ project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradle's cross project configuration _every_ project has to be evaluated before _any_ task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to `bluewhale` and `krill`.
  
  .Example: Evaluation and execution of projects
  ====
  include::sample[dir="userguide/multiproject/partialTasks/water/groovy",files="bluewhale/build.gradle[];krill/build.gradle[]"]
  include::sample[dir="userguide/multiproject/partialTasks/water/kotlin",files="bluewhale/build.gradle.kts[];krill/build.gradle.kts[]"]
  ====
  
  .Output of `gradle -q distanceToIceberg`
  ----
  
negative.code: 
  Gradle's multi-project features are driven by real life use cases. One good example consists of two web application projects and a parent project that creates a distribution including the two web applications.footnote:[The real use case we had, was using http://lucene.apache.org/solr[], where you need a separate war for each index you are accessing. That was one reason why we have created a distribution of webapps. The Resin servlet container allows us, to let such a distribution point to a base installation of the servlet container.] For the example we use only one build script and do _cross project configuration_.
  
  .Dependencies - real life example - crossproject configuration
  ====
  [.multi-language-sample]
  =====
  .Project layout
  [source, groovy]
  ----
  .
  ├── build.gradle
  