anchor.diff:  
   [source,xml,indent=0]
   ----
  -Unresolved directive in verifier/introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/1.0.x/samples/standalone/dsl/http-client/pom.xml[tags=contract_bom,indent=0]
  +<dependencyManagement>
  +    <dependencies>
  +        <dependency>
  +            <groupId>org.springframework.cloud</groupId>
  +            <artifactId>spring-cloud-dependencies</artifactId>
  +            <version>${spring-cloud-dependencies.version}</version>
  +            <type>pom</type>
  +            <scope>import</scope>
  +        </dependency>
  +    </dependencies>
  +</dependencyManagement>
   ----
   
   Add the dependency to `Spring Cloud Contract Stub Runner`
   
   [source,xml,indent=0]
   ----
  -Unresolved directive in verifier/introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/1.0.x/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
  +<dependency>
  +    <groupId>org.springframework.cloud</groupId>
  +    <artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
  +    <scope>test</scope>
  +</dependency>
   ----
   
   Annotate your test class with `@AutoConfigureStubRunner`. In the annotation provide the group id and artifact id for the Stub Runner to download stubs of your collaborators. Also provide the offline work switch since you're playing with the collaborators offline (optional step).
   
   [source,groovy,indent=0]
   ----
  -Unresolved directive in verifier/introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/1.0.x/samples/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=autoconfigure_stubrunner,indent=0]
  +@RunWith(SpringRunner.class)
  +@SpringBootTest(webEnvironment=WebEnvironment.NONE)
  +@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
  +@DirtiesContext
  +public class LoanApplicationServiceTests {
   ----
   
   Now if you run your tests you'll see sth like this:
  
positive.code: 
  [source,groovy,indent=0]
  ----
  Unresolved directive in verifier/introduction.adoc - include::https://raw.githubusercontent.com/spring-cloud/spring-cloud-contract/1.0.x/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
  
  The Contract is written using a statically typed Groovy DSL. You might be wondering what are those
  `value(client(...), server(...))` parts. By using this notation Spring Cloud Contract allows you to
  
negative.code: 
  == Contributing
  
  Spring Cloud is released under the non-restrictive Apache 2.0 license,
  and follows a very standard Github development process, using Github
  tracker for issues and merging pull requests into master. If you want
  to contribute even something trivial please do not hesitate, but
  follow the guidelines below.
  
  === Sign the Contributor License Agreement
  Before we accept a non-trivial patch or pull request we will need you to sign the
  https://support.springsource.com/spring_committer_signup[contributor's agreement].
  Signing the contributor's agreement does not grant anyone commit rights to the main
  repository, but it does mean that we can accept your contributions, and you will get an
  author credit if we do.  Active contributors might be asked to join the core team, and
  given the ability to merge pull requests.
  
  === Code Conventions and Housekeeping
  None of these is essential for a pull request, but they will all help.  They can also be
  added after the original pull request but before a merge.
  
  * Use the Spring Framework code format conventions. If you use Eclipse
    you can import formatter settings using the
    `eclipse-code-formatter.xml` file from the
    https://github.com/spring-cloud/build/tree/master/eclipse-coding-conventions.xml[Spring
    Cloud Build] project. If using IntelliJ, you can use the
    http://plugins.jetbrains.com/plugin/6546[Eclipse Code Formatter
    Plugin] to import the same file.
  * Make sure all new `.java` files to have a simple Javadoc class comment with at least an
    `@author` tag identifying you, and preferably at least a paragraph on what the class is
    for.
  * Add the ASF license header comment to all new `.java` files (copy from existing files
    in the project)
  * Add yourself as an `@author` to the .java files that you modify substantially (more
    than cosmetic changes).
  * Add some Javadocs and, if you change the namespace, some XSD doc elements.
  * A few unit tests would help a lot as well -- someone has to do it.
  * If no-one else is using your branch, please rebase it against the current master (or
    other target branch in the main project).
  * When writing a commit message please follow http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[these conventions],
    if you are fixing an existing issue please add `Fixes gh-XXXX` at the end of the commit
    message (where XXXX is the issue number).
  
  == How to build it
  
  IMPORTANT: You need to have all the necessary Groovy plugins
  