anchor.diff:  These are a way to enable and disable different configurations based on environment, target platform, or any other similar factor.
   Logically, they are nothing more than limited ‘if' statements.
   And since Gradle has much more powerful ways to declare conditions, it does not need to have formal support for profiles (except in the POMs of dependencies).
  -You can easily get the same behavior by combining conditions with secondary build files, as you'll see next.
  -
  -Let's say you have different deployment settings depending on environment: local development (the default), a test environment, and production.
  -To add profile-like behavior, first create build files for each environment in the project root: `profile-default.gradle`, `profile-test.gradle`, and `profile-prod.gradle`.
  -Next, add a condition similar to the following to the main build file:
  +You can easily get the same behavior by combining conditions with secondary build scripts, as you'll see.
  +
  +Let's say you have different deployment settings depending on the environment: local development (the default), a test environment, and production.
  +To add profile-like behavior, you first create build scripts for each environment in the project root: `profile-default.gradle`, `profile-test.gradle`, and `profile-prod.gradle`.
  +Next, you add a condition like this to the main build script:
   
   [source,groovy]
   ----
  
positive.code: apply from: "profile-${buildProfile}.gradle"
  ----
  
  All you have to do then is put the environment-specific configuration, such as project properties, dependencies, etc., in the corresponding build file.
  To activate a particular profile, you can just pass in the relevant project property on the command line:
  
  [listing.terminal]
  
negative.code: Gradle has a similar system of project properties, although it differentiates between those and system properties.
  You can, for example, define properties in:
  
  * the build script
  * a `gradle.properties` file in the root project directory
  * a `gradle.properties` file in the `$HOME/.gradle` directory
  
  Those aren't the only options, so if you are interested in finding out more about how and where you can define properties, check out the <<build_environment#build_environment,Build Environment>> chapter.
  
  One important piece of behavior you need to be aware of is what happens when the same property is defined in both the build script and one of the external properties files: the build script value takes precedence.
  Always.
  Fortunately, you can mimic the concept of profiles to provide overridable default values.
  
  