anchor.diff:  > gradle -q release
   include::{samplesPath}/userguide/tutorial/configByDag/configByDag.out[]
   ----
  +====
   
   The important thing is that `whenReady` affects the release task _before_ the release task is executed. This works even when the release task is not the _primary_ task (i.e., the task passed to the `gradle` command).
   
  
positive.code: 
  You can add your own properties to a task. To add a property named `myProperty`, set `ext.myProperty` to an initial value. From that point on, the property can be read and set like a predefined task property.
  
  === Example: Adding extra properties to a task
  
  [source.multi-language-sample,groovy]
  .build.gradle
  ----
  include::{samplesPath}/userguide/tutorial/extraProperties/build.gradle[tag=taskProperties]
  ----
  
  .Output of **`gradle -q printTaskProperties`**
  ----
  > gradle -q printTaskProperties
  include::{samplesPath}/userguide/tutorial/extraProperties/extraTaskProperties.out[]
  ----
  
  Extra properties aren't limited to tasks. You can read more about them in <<writing_build_scripts.adoc#sec:extra_properties,Extra properties>>.
  
  
negative.code: 
  There is a convenient notation for accessing an _existing_ task. Each task is available as a property of the build script:
  
  .Accessing task as a property of the build script
  ====
  include::sample[dir="userguide/tutorial/helloWithShortCut", files="build.gradle[]"]
  
  .Output of **`gradle -q hello`**
  ----
  > gradle -q hello
  include::{samplesPath}/userguide/tutorial/helloWithShortCut/helloWithShortCut.out[]
  ----
  ====
  
  This enables very readable code, especially when using the tasks provided by the plugins, like the `compile` task.
  
  