anchor.diff:  
   [TIP]
   ====
  -This is just a demonstration of how to go about performing a migration in stages. It may make more sense to include resource processing — like properties files — and packaging with the compilation in this stage, since all three aspects are well integrated in Gradle.
  +This is just a demonstration of how to go about performing a migration in stages. It may make more sense to include resource processing — like with properties files — and packaging with the compilation in this stage, since all three aspects are well integrated in Gradle.
   ====
   
   One important question you will have to ask yourself is how many tasks to migrate in each stage. The larger the chunks you can migrate in one go the better, but this must be offset against how many custom steps within the Ant build will be affected by the changes.
   
   For example, if the Ant build follows a fairly standard approach for compilation, static resources, packaging and unit tests, then it is probably worth migrating all those together. But if the build performs some extra processing on the compiled classes, or does something unique when processing the static resources, it is probably worth splitting those tasks into separate stages.
   
  +[[migant:managing_dependencies]]
   == Managing dependencies
   
  -Ant builds typically take one of two approaches to dealing with dependencies:
  +Ant builds typically take one of two approaches to dealing with binary <<dependency_management_terminology#sub:terminology_dependency,dependencies>> (such as libraries):
   
    * Storing them with the project in a local "lib" directory
  - * Using https://ant.apache.org/ivy/[Ivy] to manage them
  -
  -Gradle can work with either situation with the appropriate configuration.
  -
  + * Using https://ant.apache.org/ivy/[Apache Ivy] to manage them
  +
  +They each require a different technique for the migration to Gradle, but you will find the process straightforward in either case. We look at the details of each scenario in the following sections.
  +
  +[[migant:filesystem_deps]]
   === Serving dependencies from a directory
   
  -You can use local dependencies with Gradle in one of two ways:
  +When you are attempting to migrate a build that stores its dependencies on the filesystem, either locally or on the network, you should consider whether you want to eventually move to managed dependencies using remote repositories. That's because you can incorporate filesystem dependencies into a Gradle build in one of two ways:
   
    * Define a <<repository_types#sec:flat_dir_resolver,flat-directory repository>> and use standard dependency declarations
  - * Attach the files directly to the appropriate dependency configurations — these are known as <<declaring_dependencies#sec:declaring_file_dependency,file dependencies>>
  -
  -It's easier to migrate to managed dependencies served from Maven- or Ivy-compatible repositories if you take the first approach, but doing so requires all your files to have a version in their name.
  + * Attach the files directly to the appropriate dependency configurations (<<declaring_dependencies#sec:declaring_file_dependency,file dependencies>>)
  +
  +It's easier to migrate to managed dependencies served from Maven- or Ivy-compatible repositories if you take the first approach, but doing so requires all your files to conform to the naming convention "<moduleName>-<version>.<extension>".
  +
  +[NOTE]
  +====
  +If you store your dependencies in the standard Maven repository layout — `<repoDir>/<group>/<module>/<version>` — then you can define a <<declaring_repositories#sec:declaring_custom_repository,custom Maven repository>> with a "file://" URL.
  +====
   
   To demonstrate the two techniques, consider a project that has the following library JARs in its `libs` directory:
   
  
positive.code: +
  This step very much depends on the requirements of your build. If a selection of Gradle plugins can do the vast majority of the work your Ant build does, then it probably makes sense to create a fresh Gradle build script that doesn't depend on the Ant build and either implements the missing pieces itself or <<ant#sec:using_ant_tasks,utilizes existing Ant tasks>>.
  +
  The alternative approach is to <<ant#sec:import_ant_build,import the Ant build>> into the Gradle build script and gradually replace the Ant build functionality with...TBC
   6. Configure your build for the existing directory and file structure
  +
  Gradle makes use of conventions to eliminate much of the boilerplate associated with older builds and to make it easier for users to work with new builds once they are familiar with those conventions. But that doesn't mean you have to follow them.
  
negative.code: 
  Gradle does use something similar in the form of <<build_environment#sec:project_properties,project properties>>, which are a reasonable way to parameterize a build. These can be set from the command line, in a <<build_environment#sec:gradle_configuration_properties,`gradle.properties` file>>, or even via specially named system properties and environment variables.
  
  If you have existing Ant properties files, you can copy their contents into the project's `gradle.properties` file. Just be aware of two important points:
  
   * Properties set in `gradle.properties` **do not** override <<writing_build_scripts#sec:extra_properties,extra project properties>> defined in the build script with the same name
   * Imported Ant tasks will not automatically "see" the Gradle project properties — you must copy them into the Ant properties map for that to happen
  
  Another important factor to understand is that a Gradle build script works with an object-oriented API and it's often best to use the properties of tasks, source sets and other objects where possible. For example, this build script fragment creates tasks for packaging Javadoc documentation as a JAR and unpacking it, linking tasks via their properties:
  
  [source,groovy]
  ----
  