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: That's why many projects incorporate some form of higher level testing, sometimes termed integration, functional or acceptance testing.
  
  Maven supports these types of test by providing an extra set of phases: `pre-integration-test`, `integration-test`, `post-integration-test`, and `verify`.
  It also uses the Failsafe plugin rather than Surefire so that failed integration tests don't automatically fail the build (because you may need to clean up resources, such as a running application server).
  
  Another factor to consider is where you keep your integration test classes.
  The default approach is to mix them with your unit test classes, but this is less than ideal.
  A common alternative is to use profiles so that you can keep the two types of test separate.
  
  So how should you approach migrating such a setup to Gradle? Forget plugins: source sets are your friends in this situation.
  A standard Java project already has two source sets for your main classes and your unit tests.
  Why not add an extra one for integration tests? Or even more than one for different types of integration test? Say low-level tests against a live database and higher level tests with something like FitNesse.
  
  By declaring a new source set, Gradle automatically sets you up with corresponding configurations (`[sourceSet]Compile` and `[sourceSet]Runtime`) as well as compilation tasks (`compile[SourceSet][Lang]`) and a resource processing task (`process[SourceSet]Resources`).
  All you need to do is add a task to run the tests and ensure that the classpaths are all set up.
  You might also want to add tasks for starting/stopping a database or application server if your tests require something like that.
  
  Let's now take a look at an example so you can see what's involved in practice:
  
  .Configuring a source set for integration tests
  ====
  include::sample[dir="userguide/mavenMigration/integrationTests/groovy",files="build.gradle[tags=sourcesets]"]
  ====
  
  In the above example, I create a new source set called `integTest`.
  I also make sure that the application or library classes, as well as their dependencies, are included on the classpath when compiling the integration tests.
  
  Your integration tests will probably use some third party libraries of their own, so you'll want to add those the compilation classpath too.
  That's done in the normal way in the `dependencies` block:
  
  .Adding dependencies for compiling and running integration tests
  ====
  include::sample[dir="userguide/mavenMigration/integrationTests/groovy",files="build.gradle[tags=dependencies]"]
  ====
  
  The integration tests will now compile, but there is currently no way to run them. That's where the custom `Test` task comes in:
  
  .Creating a task that runs the integration tests
  ====
  include::sample[dir="userguide/mavenMigration/integrationTests/groovy",files="build.gradle[tags=testtask]"]
  ====
  
  In the above example, I'm assuming that the integration tests run against an application server that needs to be started and shut down at the appropriate times.
  You can learn more about how and what to configure on the `Test` task in Gradle's link:{groovyDslPath}/org.gradle.api.tasks.testing.Test.html[DSL Reference].
  
  All that's left to do at this point is incorporate the `integTest` task into your task graph, for example by having `build` depend on it.
  It's really up to you how you fit it into the build.
  If you want to support other test types, just rinse and repeat.
  
  
  == Migrating common plugins
  
  Maven and Gradle share a common approach of extending the build through plugins.
  
negative.code: apply from: "profile-${buildProfile}.gradle"
  ----
  
  All you have to do then is put the environment-specific configuration, such as project properties, dependencies, etc., in the corresponding build script.
  To activate a particular profile, you can just pass in the relevant project property on the command line:
  
  [listing.terminal]
  