anchor.diff:  }
   ----
   
  -While the same contract expressed in YAML would look the following way:
  +The same contract expressed in YAML would look like the following example:
   
   [source,yaml,indent=0]
   ----
  
positive.code: public class LoanApplicationServiceTests {
  ----
  
  Now in your integration test, you will be able to receive stubbed versions of HTTP responses or messages that are
  expected to be emitted by the collaborator service. You will see entries similar to theses in the build logs:
  
  [source,bash,indent=0]
  ----
  
negative.code:     Content-Type: application/json;charset=UTF-8
  ----
  
  In the case of messaging, you can define:
  
  * The input and the output messages can be defined (taking into account from and where it
  was sent, the message body, and the header).
  * The methods that should be called after the message is received.
  * The methods that, when called, should trigger a message.
  
  The following example shows a Camel messaging contract expressed in Groovy DSL:
  
  [source,groovy]
  ----
  include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MessagingMethodBodyBuilderSpec.groovy[tags=trigger_no_output_dsl]
  ----
  
  The following example shows the same contract expressed in YAML:
  
  [source,yml,indent=0]
  ----
  include::{verifier_core_path}/src/test/resources/yml/contract_message_scenario3.yml[indent=0]
  ----
  
  Then you can add Spring Cloud Contract Verifier dependency and plugin to your build file,
  as shown in the following example:
  
  [source,xml,indent=0]
  ----
  include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
  ----
  
  The following listing shows how to add the plugin, which should go in the build/plugins
  portion of the file:
  
  [source,xml,indent=0]
  ----
  