Changed client / server to consumer / producer

docs/src/main/asciidoc/verifier/contract.adoc

@@ -97,7 +97,35 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 
 Besides status response may contain **headers** and **body**, which are specified the same way as in the request (see previous paragraph).
 
+==== Dynamic properties
+
+The contract can contain some dynamic properties - timestamps / ids etc. You don't want to enforce the consumers to stub their
+clocks to always return the same value of time so that it gets matched by the stub. That's why we allow you to provide the dynamic
+parts in your contracts in the following way
+
+either via the `value` method
+
+[source,groovy,indent=0]
+----
+value(consumer(...), producer(...))
+value(stub(...), test(...))
+value(client(...), server(...))
+----
+
+or if you're using the Groovy map notation for body you can use the `$()` method
+
+[source,groovy,indent=0]
+----
+$(consumer(...), producer(...))
+$(stub(...), test(...))
+$(client(...), server(...))
+----
+
+All of the aforementioned approaches are equal. That means that `stub` and `client` methods are aliases over the `consumer`
+method. Let's take a closer look at what we can do with those values in the subsequent sections.
+
 ==== Regular expressions
+
 You can use regular expressions to write your requests in Contract DSL. It is particularly useful when you want to indicate that a given response
 should be provided for requests that follow a given pattern. Also, you can use it when you need to use patterns and not exact values both
 for your test and your server side tests.
@@ -119,6 +147,20 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 
 In this example for request and response the opposite side of the communication will have the respective data generated.
 
+Spring Cloud Contract comes with a series of predefined regular expressions that you can use in your contracts.
+
+[source,groovy,indent=0]
+----
+include::{contract_spec_path}/src/main/groovy/org/springframework/cloud/contract/spec/internal/RegexPatterns.groovy[tags=regexps,indent=0]
+----
+
+so in your contract you can use it like this
+
+[source,groovy,indent=0]
+----
+include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MockMvcMethodBodyBuilderSpec.groovy[tags=contract_with_regex,indent=0]
+----
+
 
 ==== Passing optional parameters
 

docs/src/main/asciidoc/verifier/introduction.adoc

@@ -160,7 +160,7 @@ As consumers we need to define what exactly we want to achieve. We need to formu
 include::{introduction_url}/samples/standalone/http-server/src/test/resources/contracts/shouldMarkClientAsFraud.groovy[]
 ----
 
-The Contract is written using a statically typed Groovy DSL. You might be wondering what are those `${value(client(...), server(...))}` parts. So the `${}` is a String interpolation in Groovy. You can resolve a variable inside a String. In other words `"concat ${foo} and ${bar}"` is the same as `"concat " + foo + " and " + bar`. The `value(client(...), server(...))` allows you to define parts of a JSON which are dynamic. In case of an identifier or a timestamp you don't want to hardcode a value. You want to allow some different ranges of values. That's why for the consumer side you can set regular expressions matching those values. You can provide the body either by means of String with interpolations or with a map notation. https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_contract_dsl[Consult the docs for more information.]
+The Contract is written using a statically typed Groovy DSL. You might be wondering what are those `${value(consumer(...), producer(...))}` parts. So the `${}` is a String interpolation in Groovy. You can resolve a variable inside a String. In other words `"concat ${foo} and ${bar}"` is the same as `"concat " + foo + " and " + bar`. The `value(consumer(...), producer(...))` allows you to define parts of a JSON which are dynamic. In case of an identifier or a timestamp you don't want to hardcode a value. You want to allow some different ranges of values. That's why for the consumer side you can set regular expressions matching those values. You can provide the body either by means of String with interpolations or with a map notation. https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract.html#_contract_dsl[Consult the docs for more information.]
 
 The aforementioned contract is an agreement between two sides that:
 
@@ -363,7 +363,7 @@ public void validate_shouldMarkClientAsFraud() throws Exception {
 }
 ----
 
-As you can see all the `server()` parts of the Contract that were present in the `value(client(...), server(...))` blocks got injected into the test.
+As you can see all the `producer()` parts of the Contract that were present in the `value(consumer(...), producer(...))` blocks got injected into the test.
 
 What's important here to note is that on the producer side we also are doing TDD. We have expectations in form of a test. This test is shooting a request to our own application to an URL, headers and body defined in the contract. It also is expecting very precisely defined values in the response. In other words you have is your `red` part of `red`, `green` and `refactor`. Time to convert the `red` into the `green`.
 

docs/src/main/asciidoc/verifier/spring-cloud-contract-verifier.adoc

@@ -1,6 +1,7 @@
 :core_path: ../../../../..
 :plugins_path: ../../../../../spring-cloud-contract-tools
 :verifier_root_path: {core_path}/spring-cloud-contract-verifier
+:contract_spec_path: {core_path}/spring-cloud-contract-spec
 :samples_path: {core_path}/samples
 :verifier_core_path: {verifier_root_path}
 :stubrunner_core_path: {core_path}/spring-cloud-contract-stub-runner