anchor.diff:  
   Once that's all done, you'll be able to generate an Ivy module descriptor for each publication and publish them to one or more repositories.
   
  -Let's say you have defined a publication named "myLibrary" and a repository named "myRepo". The Ivy tasks would then map to the Gradle tasks like this:
  +Let's say you have defined a publication named "myLibrary" and a repository named "myRepo". Ivy's Ant tasks would then map to the Gradle tasks like this:
   
    * `<deliver>` -> `generateDescriptorFileForMyLibraryPublication`
    * `<publish>` -> `publishMyLibraryPublicationToMyRepoRepository`
   
  -There is also a `publish` task that publishes all publications to all repositories. You could also define your own aggregate task that depends on just a subset of those publishing tasks.
  +There is also a convenient `publish` task that publishes _all_ publications to _all_ repositories. If you'd prefer to limit which publications go to which repositories, check out the <<publishing_overview.html#publishing_maven:conditional_publishing,relevant section of the Publishing chapter>>.
   
   .On dependency versions
   [NOTE]
  
positive.code:  2. _Resolve_ — locates the declared dependencies and downloads them to the cache if necessary
   3. _Retrieve_ — copies the cached dependencies to another directory
  
  Gradle's process is similar, but you don't have to explicitly invoke the first two steps. It performs them automatically. The third step doesn't happen at all — unless you create a task to do it — because Gradle typically uses the files in the dependency cache directly in classpaths and as the source for assembling application packages.
  
  Let's look at how Ivy's steps map to Gradle:
  
  Configuration::
  Most of Gradle's dependency-related configuration is baked into the build script, as you've seen with elements like the `dependencies {}` block. Another particularly important configuration element is link:{groovyDslPath}/org.gradle.api.artifacts.ResolutionStrategy.html[resolutionStrategy], which is accessible on dependency configurations. This provides many of the features you might get from Ivy's conflict managers and is a powerful way to control transitive dependencies and caching.
  +
  Some Ivy configuration options have no equivalent in Gradle. For example, there are no lock strategies because Gradle ensures that its dependency cache is concurrency safe, period. Nor are there "latest strategies" because it's simpler to have a reliable, single strategy for conflict resolution. If the "wrong" version is picked, you can easily override it using forced versions or other resolution strategy options.
  +
  See the chapters on <<managing_transitive_dependencies#managing_transitive_dependencies,Managing Transitive Dependencies>> and <<customizing_dependency_resolution_behavior#customizing_dependency_resolution_behavior,Customizing Dependency Resolution Behavior>> for more information on this aspect of Gradle.
  
  Resolution::
  Gradle will automatically resolve any dependencies you have declared and download them to its cache. It searches for dependencies in the repositories, with the search order defined by <<declaring_repositories#sec:declaring_multiple_repositories,the order in which the repositories declared>>.
  +
  It's worth noting that Gradle supports the same dynamic version syntax as Ivy, so you can still use versions like `1.0.+`. You can also use the special `latest.integration` and `latest.release` labels if you wish. You can also configure the caching behavior for dynamic and changing versions via link:{groovyDslPath}/org.gradle.api.artifacts.ResolutionStrategy.html[resolutionStrategy].
  
  Retrieval::
  As mentioned, Gradle does not automatically copy files from the dependency cache. Its standard tasks typically use the files directly. If you want to copy the dependencies to a local directory, you can use something like this in your build script:
  +
  [source,groovy]
  ----
  
negative.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. 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.
  