anchor.diff:  +
   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
  +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. This allows you to have a working Gradle build at each stage, but it requires a bit of work to get the Gradle tasks working properly with the Ant ones. You can learn more about this approach in <<migant:imported_builds,Working with an imported build>>.
    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.
  
positive.code: .On paths and filesets
  [NOTE]
  ====
  Ant makes use of the concepts of path-like structures and filesets to enable users to work with collections of files and directories. Gradle has a simpler, more powerful model based on link:{javadocPath}/org/gradle/api/file/FileCollection.html[FileCollection]s and link:{javadocPath}/org/gradle/api/file/FileTree.html[FileTree]s that can be treated as objects from within the build. Both types of file collection support filtering that uses Ant's glob syntax, e.g. `**/books_*`. Learn more about both types in the <<working_with_files#working_with_files,Working with Files>> chapter.
  
  You can still construct Ant paths and filesets from within your build if you need to interact with an Ant task that requires them. There is even link:{javadocPath}/org/gradle/api/file/FileCollection.html#addToAntBuilder-java.lang.Object-java.lang.String-org.gradle.api.file.FileCollection.AntType-[a method on `FileCollection`] for converting a file collection to a fileset or similar Ant type.
  ====
  
  == Migrating Ant properties
  
  Ant makes use of a properties map to store values that can be reused through the build. The big downsides to this approach are that property values are all strings and the properties themselves behave like global variables.
  
  .Interacting with Ant properties in Gradle
  [TIP]
  
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]
  ----
  