anchor.diff:  For a lengthier discussion on working with Maven profiles in Gradle, look no further than http://gradle.org/feature-spotlight-gradles-support-maven-pom-profiles[this article] by Benjamin Muschko.
   
   
  +[[migmvn:filtering_resources]]
   == Filtering resources
   
   Maven has a phase called `process-resources` that has the goal `resources:resources` bound to it by default.
   This gives the build author an opportunity to perform variable substitution on various files, such as web resources, packaged properties files, etc.
   
   The Java plugin for Gradle provides a `processResources` task to do the same thing.
  -Here's an example configuration:
  -
  -.Filtering resources via the `processResources` task
  +This is a link:{groovyDslPath}/org.gradle.api.tasks.Copy.html[Copy] task that copies files from the configured resources directory -- `src/main/resources` by default -- to an output directory.
  +And as with any `Copy` task, you can configure it to perform <<working_with_files#filtering_files,file filtering>>, <<working_with_files#sec:renaming_files,renaming>>, and <<working_with_files#sec:filtering_files,content filtering>>.
  +
  +As an example, here's a configuration that treats the source files as http://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html#_simpletemplateengine[Groovy `SimpleTemplateEngine`] templates, providing `version` and `buildNumber` properties to those templates:
  +
  +.Filtering the content of resources via the `processResources` task
   ====
   include::sample[dir="userguide/mavenMigration/resourceFiltering/groovy",files="build.gradle[tags=process-resources]"]
   ====
   
  -So the left hand side of each colon is the token name and the right hand side is a project property.
  -This variable substitution will apply to all your resource files (the ones under `src/main/resources` usually).
  -
  -Gradle has other powerful ways for property processing.
  -You can hook in your own filter via a closure that allows you to process the content line by line, or you can add your own `FilterReader` implementation.
  -For more details, see the documentation for the link:{javadocPath}/org/gradle/api/file/ContentFilterable.html[ContentFilterable] interface which all copy and archive tasks implement.
  -
  -
  +See the API docs for link:{javadocPath}/org/gradle/api/file/CopySpec.html[CopySpec] to see all the options available to you.
  +
  +
  +[[migmvn:integration_tests]]
   == Configuring integration tests
   
   Although unit tests are very useful, they can't ensure that an application or library works as a whole.
  
positive.code: Gradle is now 2-10x faster than Maven for the vast majority of projects, even without using a build cache.
  In-depth performance comparison and business cases for switching from Maven to Gradle can be found link:https://gradle.org/gradle-vs-maven-performance/[here].
  
  [[migmvn:understanding_the_differences]]
  == Understanding the functional differences
  
  Gradle and Maven have fundamentally different views on how to build a project.
  Gradle is based on a <<what_is_gradle#2_the_core_model_is_based_on_tasks,_graph of task dependencies_>>, where the tasks do the work.
  Maven uses a model of fixed, linear phases to which you can attach goals (the things that do the work).
  Despite this, migrations can be surprisingly easy because Gradle follows many of the same conventions as Maven and dependency management works in a similar way.
  
  One especially useful feature for understanding your new Gradle build is link:https://scans.gradle.com/[build scans]: these are  web-based snapshots of a given build that allows collaborative debugging and fine-grained performance analysis.
  For example, here's the link:https://scans.gradle.com/s/u7uyv3vuyhrig/timeline[build timeline for the Groovy build]:
  
  image:groovy-build-scan.png[]
  
  You can use build scans to debug dependency resolution, Gradle task execution, and many other aspects of your build.
  
  Once you've decided to go ahead with the migration, what should you do first? The best starting point is _recording the inputs and outputs_ of your Maven build, so that you can verify that your new Gradle build is functionally equivalent.
  
  
  [[migmvn:automatic_conversion]]
  == Performing an automatic conversion
  
  Not only will the <<build_init_plugin#build_init_plugin,Gradle `init` task>> allow you to create a new skeleton project, but it will also automatically convert an existing Maven one to Gradle.
  All you have to do is run the command
  
  [listing.terminal]
  
negative.code: To learn more, see <<ant#ant,Using Ant from Gradle>>.
  
  
  [[migmvn:unnecessary_plugins]]
  == Understanding which plugins you don't need
  
  It's worth remembering that Gradle builds are typically easier to extend and customize than Maven ones.
  In this context, that means you may not need a Gradle plugin to replace a Maven one.
  For example, the Maven Enforcer plugin allows you to control dependency versions and environmental factors, but these things can easily be configured in a normal Gradle build script.
  
  
  [[migmvn:custom_plugins]]
  == Dealing with uncommon and custom plugins
  
  You may come across Maven plugins that have no counterpart in Gradle, particularly if you or someone in your organisation has written a custom plugin.
  Such cases rely on you understanding how Gradle (and potentially Maven) works, because you will usually have to write your own plugin.
  
  For the purposes of migration, there are two key types of Maven plugins:
  
  * Those that use the Maven project object.
  * Those that don't.
  
  Why is this important? Because if you use one of the latter, you can trivially reimplement it as a <<custom_tasks#custom_tasks,custom Gradle task type>>.
  Simply define task inputs and outputs that correspond to the mojo parameters and convert the execution logic into a task action.
  
  If a plugin depends on the Maven project, then you will have to rewrite it.
  Don't start by considering how the Maven plugin works, but look at what problem it is trying to solve.
  Then try to work out how to solve that problem in Gradle.
  You'll probably find that the two build models are different enough that "transcribing" Maven plugin code into a Gradle plugin just won't be effective.
  On the plus side, the plugin is likely to be much easier to write than the original Maven one because Gradle has a much richer build model and API.
  
  If you do need to implement custom logic, either via build scripts or plugins, then be sure to familiarize yourself with Gradle's link:{groovyDslPath}/[Groovy DSL Reference], which provides comprehensive documentation on the API that you'll be working with.
  It details the standard configuration blocks (and the objects that back them), the core types in the system (`Project`, `Task`, etc.), and the standard set of tasks.
  The main entry point is the `Project` interface as that's the top-level object that backs the build scripts.
  
  == Further reading
  
  This chapter has covered the major topics that are specific to migrating Ant builds to Gradle. All that remain are a few other areas that may be useful during or after a migration:
  
   * Learn how to configure Gradle's <<build_environment#build_environment,build environment>>, including the JVM settings used to run it
   * Learn how to <<organizing_gradle_projects#organizing_gradle_projects,structure your builds effectively>>
   * <<logging#logging,Configure Gradle's logging>> and use it from your builds
  
  As a final note, this guide has only touched on a few of Gradle's features and we encourage you to learn about the rest from the other chapters of the user manual and from our tutorial-style link:{guidesUrl}/[Gradle Guides].
  