anchor.diff:  You can replicate the default Ivy behavior by using the https://plugins.gradle.org/plugin/nebula.ivy-resolved-dependencies[Nebula Ivy Resolved Plugin]. Alternatively, you can link:{groovyDslPath}/org.gradle.api.publish.ivy.IvyModuleDescriptorSpec.html#org.gradle.api.publish.ivy.IvyModuleDescriptorSpec:withXml(org.gradle.api.Action)[customize the descriptor file] so that it contains the versions you want.
   ====
   
  -== Dealing with custom tasks
  -
  -One of the advantages of Ant is that it's fairly easy to create a custom task and incorporate it into a build. If you have such tasks, then you have two main options for a migration:
  -
  - * <<ant#sec:using_custom_ant_tasks,Use the custom Ant task>> from the Gradle build
  - * Rewrite the task as a <<custom_tasks#custom_tasks,custom Gradle task type>>
  +[[migant:custom_tasks]]
  +== Dealing with custom Ant tasks
  +
  +One of the advantages of Ant is that it's fairly easy to create a custom task and incorporate it into a build. If you have such tasks, then there are two main options for migrating them to a Gradle build:
  +
  + * <<ant#sec:using_custom_ant_tasks,Using the custom Ant task>> from the Gradle build
  + * Rewriting the task as a <<custom_tasks#custom_tasks,custom Gradle task type>>
   
   The first option is usually quick and easy, but not always. And if you want to integrate the task into incremental build, you must use the <<more_about_tasks#sec:task_input_output_runtime_api,incremental build runtime API>>. You also often have to work with Ant paths and filesets, which are clunky.
   
  
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: </target>
  ----
  +
  This can be replaced by an inter-project task dependency in the corresponding Gradle build script, as demonstrated in the following example that assumes the "web" project's "compile" task is the thing that requires "util" to be built beforehand:
  +
  .web/build.gradle
  [source,groovy]
  