anchor.diff:  [[sec:minimize_logic_executed_configuration_phase]]
   === Minimize logic executed during the configuration phase
   
  -It's important for every build script developer to understand the different phases of the <<build_lifecycle,build lifecycle>> and their implications on performance and evaluation order of build logic. During the configuration phase the project and its domain objects should be _configured_, whereas the execution phase only executes the actions of the task(s) requested on the command line plus their dependencies. Be aware that any code that is not part of a task action will be executed with _every single run_ of the build. A link:https://scans.gradle.com/get-started[build scan] can help you with identifying the time spent during each of the lifecycle phases. It's an invaluable tool for diagnosing common performance issues.
  -
  -Let's consider the following incantation of the anti-pattern described above. In the build script you can see that the dependencies assigned to the configuration `printArtifactNames` are resolved outside of the task action.
  +It's important for every build script developer to understand the different phases of the <<build_lifecycle,build lifecycle>> and their implications on performance and evaluation order of build logic.
  +During the configuration phase the project and its domain objects should be _configured_, whereas the execution phase only executes the actions of the task(s) requested on the command line plus their dependencies.
  +Be aware that any code that is not part of a task action will be executed with _every single run_ of the build.
  +A link:https://scans.gradle.com/get-started[build scan] can help you with identifying the time spent during each of the lifecycle phases.
  +It's an invaluable tool for diagnosing common performance issues.
  +
  +Let's consider the following incantation of the anti-pattern described above.
  +In the build script you can see that the dependencies assigned to the configuration `printArtifactNames` are resolved outside of the task action.
   
   ++++
   <sample id="logicDuringConfigurationPhase" dir="userguide/bestPractices/logicDuringConfiguration/dont" title="Executing logic during configuration should be avoided">
  
positive.code: 
  ==== Alternatives for oft-used internal APIs
  
  To provide a nested DSL for your custom task, don't use `org.gradle.internal.reflect.Instantiator`; use api:org.gradle.api.model.ObjectFactory[] instead. It may also be helpful to read <<lazy_configuration>>.
  
  Don't use `org.gradle.api.internal.ConventionMapping`. Use api:org.gradle.api.provider.Provider[] and/or api:org.gradle.api.provider.Property[]. You can find an example for capturing user input to configure runtime behavior in the link:https://guides.gradle.org/implementing-gradle-plugins/#capturing_user_input_to_configure_plugin_runtime_behavior[implementing plugins guide].
  
  Instead of `org.gradle.internal.os.OperatingSystem`, use another method to detect operating system, such as link:https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/SystemUtils.html[Apache commons-lang SystemUtils] or `System.getProperty("os.name")`.
  
  
negative.code: </sample>
  ++++
  
  Now that the build logic has been translated into a plugin, you can apply it in the build script.
  The build script has been shrunk from 8 lines of code to a one liner.
  
  ++++
  <sample id="conditionalLogicDo" dir="userguide/bestPractices/conditionalLogic/do" title="A build script applying a plugin that encapsulates imperative logic">
      <sourcefile file="build.gradle"/>
  </sample>
  ++++
  
  [[sec:avoiding_use_of_gradlebuild]]
  === Avoiding the use of `GradleBuild`
  
  The api:org.gradle.api.tasks.GradleBuild[] task type allows a build script to define a task that invokes another Gradle build.
  The use of this type is generally discouraged.
  There are some corner cases where the invoked build doesn't expose the same runtime behavior as from the command line or through the Tooling API leading to unexpected results.
  
  Usually, there's a better way to model the requirement.
  The appropriate approach depends on the problem at hand. Here're some options:
  
  * Model the build as <<multi_project_builds,multi-project build>> if the intention is to execute tasks from different modules as unified build.
  * Use <<composite_builds,composite builds>> for projects that are physically separated but should occasionally be built as a single unit.
  
  [[sec:avoiding_inter_project_configuration]]
  === Avoiding inter-project configuration
  
  Gradle does not restrict build script authors from reaching into the domain model from one project into another one in a <<multi_project_builds,multi-project build>>.
  Strongly-coupled projects hurts <<sec:parallel_execution,build execution performance>> as well as readability and maintainability of code.
  
  The following practices should be avoided:
  
  * Explicitly depending on a task from another project via api:org.gradle.api.Task#dependsOn(java.lang.Object...)[].
  * Setting property values or calling methods on domain objects from another project.
  * Executing another portion of the build with <<sec:avoiding_use_of_gradlebuild,GradleBuild>>.
  * Declaring unnecessary <<sec:declaring_project_dependency,project dependencies>>.
  
  [[sec:avoiding_passwords_in_plain_text]]
  === Avoiding passwords in plain text
  
  Most builds need to consume one or many passwords.
  The reasons for this need may vary.
  Some builds need a password for publishing artifacts to a secured binary repository, other builds need a password for downloading binary files.
  Passwords should always kept safe to prevent fraud.
  Under no circumstance should you add the password to the build script as property in plain text or declare it in a `gradle.properties`.
  Those files usually live in a version control repository and can be viewed by anyone that has access to it.
  
  Passwords should be stored in encrypted fashion. At the moment Gradle does not provide a built-in mechanism for encrypting, storing and accessing passwords.
  A good solution for solving this problem is the link:https://github.com/etiennestuder/gradle-credentials-plugin[Gradle Credentials plugin].
  