anchor.diff:  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.
  -
  -
  +It also uses the Failsafe plugin in place of 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).
  +
  +This behavior is easy to replicate in Gradle with source sets, as explained in our chapter on <<java_testing#sec:configuring_java_integration_tests,Testing in Java & JVM projects>>.
  +You can then configure a clean-up task, such as one that shuts down a test server for example, to always run after the integration tests regardless of whether they succeed or fail using link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:finalizedBy(java.lang.Object++[]++)[Task.finalizedBy()].
  +
  +Source sets also give you a lot of flexibility on where you place the source files for your integration tests.
  +You can easily keep them in the same directory as the unit tests or, more preferably, in a separate source directory like `src/integTest/java`.
  +To support other types of tests, you just add more source sets and link:{groovyDslPath}/org.gradle.api.tasks.testing.Test.html[Test] tasks!
  +
  +[[migmvn:common_plugins]]
   == Migrating common plugins
   
   Maven and Gradle share a common approach of extending the build through plugins.
  
positive.code: One notable feature that's missing is a standard way to share dependency versions across projects in a multi-project build.
  A common approach is to use <<writing_build_scripts#sec:extra_properties,extra properties>> in the root build script to store the versions, since those properties are visible from subprojects as well.
  
  == Migrating Maven profiles and properties
  
  Maven allows you parameterize builds using properties of various sorts.
  
negative.code: 
  NOTE: You can use this feature to apply the `<dependencyManagement>` information from any dependency's POM to the Gradle build, even those that don't have a packaging type of `pom`. However, `platform()` and `enforcedPlatform()` will ignore any dependencies declared in the `<dependencies>` block.
  
  [[migmvn:multimodule_builds]]
  == Migrating multi-module builds (project aggregation)
  
  Maven's multi-module builds map nicely to Gradle's <<multi_project_build#multi_project_build,multi-project builds>>.
  Try the corresponding link:{guidesUrl}/creating-multi-project-builds/[tutorial] to see how a basic multi-project Gradle build is set up.
  
  To migrate a multi-module Maven build, simply follow these steps:
  
  