anchor.diff:  
   Capturing user input from the build script through an extension and mapping it to input/output properties of a custom task is considered a best practice. The end user only interacts with the exposed DSL defined by the extension. The imperative logic is hidden in the plugin implementation.
   
  -The extension declaration in the build script as well as the mapping between extension properties and custom task properties occurs during Gradle's configuration phase of the build lifecycle. To avoid evaluation order issues, the actual value of a mapped property has to be resolved during the execution phase. For more information please see <<sec:build_phases>>. Gradle's API offers the mutable type api:org.gradle.api.provider.Property[] for representing a property that should be lazily evaluated e.g. during execution time. The method api:org.gradle.api.provider.Property#set(T)[] provides the value, api:org.gradle.api.provider.Provider#get()[] returns the value upon request.
  +The extension declaration in the build script as well as the mapping between extension properties and custom task properties occurs during Gradle's configuration phase of the build lifecycle. To avoid evaluation order issues, the actual value of a mapped property has to be resolved during the execution phase. For more information please see <<sec:build_phases>>. Gradle's API offers types for representing a property that should be lazily evaluated e.g. during execution time. Refer to <<lazyConfiguration> for more information.
   
   The following demonstrates the usage of the type for mapping an extension property to a task property:
   
  
positive.code:             <output args="-q hello"/>
          </sample>
  ++++
  
  The example above uses instances of api:org.gradle.api.provider.Provider[] and api:org.gradle.api.provider.Property[]. The main difference between these two interfaces is attributed to mutability. A api:org.gradle.api.provider.Provider[] is immutable and can be created with the method api:org.gradle.api.Project#provider(java.util.concurrent.Callable)[]. api:org.gradle.api.provider.Property[] extends the interface api:org.gradle.api.provider.Provider[], represents a mutable value and can be created with the method api:org.gradle.api.Project#property(java.lang.Class)[]. Please note that the provider types are not intended for implementation by build script or plugin authors.
  
  [NOTE]
  ====
  
  The api:org.gradle.api.Project[] does not provide a specific method signature for creating a provider by passing in a `groovy.lang.Closure` as parameter. When writing a plugin implementation with Groovy, you can use the method signature accepting a `java.util.concurrent.Callable` parameter. Groovy's http://docs.groovy-lang.org/next/html/documentation/core-semantics.html#_assigning_a_closure_to_a_sam_type[Closure to type coercion] will take of the rest.
  
  ====
  
  
  [[sec:custom_plugins_standalone_project]]
  === A standalone project
  
negative.code: 
  Plugin ids are fully qualified in a manner similar to Java packages (i.e. a reverse domain name). This helps to avoid collisions and provides a way to group plugins with similar ownership.
  
  Your plugin id should be a combination of components that reflect namespace (a reasonable pointer to you or your organization) and the name of the plugin it provides. For example if you had a Github account named "foo" and your plugin was named "bar", a suitable plugin id might be `com.github.foo.bar`. Similarly, if the plugin was developed at the baz organization, the plugin id might be `org.baz.bar`.
  
  Plugin ids should conform to the following:
  
  