Bumped up version and polished

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

@@ -9,6 +9,8 @@ Contract DSL is written in Groovy, but don't be alarmed if you didn't use Groovy
 a tiny subset of it (namely literals, method calls and closures). What's more the DSL is designed to be programmer-readable without any knowledge of the DSL itself -
  it's statically typed.
 
+TIP: Spring Cloud Contract supports defining multiple contracts in a single file!
+
 The Contract is present in the `spring-cloud-contract-spec` module of the Spring Cloud Contract Verifier repository.
 
 Let's look at full example of a contract definition.
@@ -26,8 +28,6 @@ Not all features of the DSL are used in example above. If you didn't find what y
 
 WARNING: Spring Cloud Contract Verifier doesn't support XML properly. Please use JSON or help us implement this feature.
 
-WARNING: Spring Cloud Contract Verifier supports equality check on text response. Regular expressions are not yet available.
-
 WARNING: The support for the verification of size of JSON arrays is experimental. If you want to turn it on please provide
 the value of a system property `spring.cloud.contract.verifier.assert.size` equal to `true`. By default this feature is set to
 `false`. You can also provide the `assertJsonSize` property in the plugin configuration.
@@ -47,6 +47,16 @@ You can add a `description` to your contract that is nothing else but an arbitra
 include::{contract_spec_path}/src/test/groovy/org/springframework/cloud/contract/spec/internal/ContractSpec.groovy[tags=description,indent=0]
 ----
 
+===== Name
+
+You can provide a name of your contract. Let's assume that you've provided a name `should register a user`.
+If you do this then the name of the autogenerated test will be equal to `validate_should_register_a_user`.
+Also the name of the stub will be `should_register_a_user.json` in case of a WireMock stub.
+
+IMPORTANT: Please ensure that the name doesn't contain any characters that will make the generated test
+ not possible to compile. Also remember that if you provide the same name for multiple contracts then your
+ autogenerated tests will fail to compile and your generated stubs will override each other.
+
 ===== Ignoring contracts
 
 If you want to ignore a contract you can either set a value of ignored contracts in the plugin configuration
@@ -111,8 +121,6 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 //include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/ContractHttpDocsSpec.groovy[tags=bodyAsXml,indent=0]
 //----
 
-
-
 ==== Response
 
 Minimal response must contain **HTTP status code**.
@@ -216,12 +224,13 @@ include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract
 
 and the following stub:
 
-[source,javascript,indent=0]
+[source,groovy,indent=0]
 ----
 include::{plugins_path}/spring-cloud-contract-converters/src/test/groovy/org/springframework/cloud/contract/verifier/wiremock/DslToWireMockClientConverterSpec.groovy[tags=wiremock,indent=0]
 ----
 
 ==== Executing custom methods on server side
+
 It is also possible to define a method call to be executed on the server side during the test. Such a method can be added to the class defined as "baseClassForTests"
 in the configuration. Please see the examples below:
 
@@ -240,7 +249,8 @@ include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/f
 ----
 
 ==== JAX-RS support
-Starting with release 0.8.0 we support JAX-RS 2 Client API. Base class needs to define `protected WebTarget webTarget` and server initialization, right now the only option how to test JAX-RS API is to start a web server.
+
+We support JAX-RS 2 Client API. Base class needs to define `protected WebTarget webTarget` and server initialization, right now the only option how to test JAX-RS API is to start a web server.
 
 Request with a body needs to have a content type set otherwise `application/octet-stream` is going to be used.
 
@@ -268,7 +278,7 @@ section a `async()` method. Example:
 ----
 org.springframework.cloud.contract.spec.Contract.make {
     request {
-        method 'GET'
+        method GET()
         url '/get'
     }
     response {
@@ -319,7 +329,86 @@ as presented below (note you can use either `$` or `value` methods to provide `c
 include::{verifier_core_path}/src/test/groovy/org/springframework/cloud/contract/verifier/builder/MessagingMethodBodyBuilderSpec.groovy[tags=consumer_producer]
 ----
 
-=== Cutomization
+==== Multiple contracts in one file
+
+It's possible to define multiple contracts in one file. An example of such a contract can look like this
+
+[source,groovy,indent=0]
+----
+include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/multiple-contracts/src/test/resources/contracts/com/hello/v1/WithList.groovy[lines=18..-1,indent=0]
+----
+
+In this example one contract has the `name` field and the other doesn't. This will lead to generation of
+two tests that will look more or less like this:
+
+[source,java,indent=0]
+----
+package org.springframework.cloud.contract.verifier.tests.com.hello;
+
+import com.example.TestBase;
+import com.jayway.jsonpath.DocumentContext;
+import com.jayway.jsonpath.JsonPath;
+import com.jayway.restassured.module.mockmvc.specification.MockMvcRequestSpecification;
+import com.jayway.restassured.response.ResponseOptions;
+import org.junit.Test;
+
+import static com.jayway.restassured.module.mockmvc.RestAssuredMockMvc.*;
+import static com.toomuchcoding.jsonassert.JsonAssertion.assertThatJson;
+import static org.assertj.core.api.Assertions.assertThat;
+
+public class V1Test extends TestBase {
+
+	@Test
+	public void validate_should_post_a_user() throws Exception {
+		// given:
+			MockMvcRequestSpecification request = given();
+
+		// when:
+			ResponseOptions response = given().spec(request)
+					.post("/users/1");
+
+		// then:
+			assertThat(response.statusCode()).isEqualTo(200);
+	}
+
+	@Test
+	public void validate_withList_1() throws Exception {
+		// given:
+			MockMvcRequestSpecification request = given();
+
+		// when:
+			ResponseOptions response = given().spec(request)
+					.post("/users/2");
+
+		// then:
+			assertThat(response.statusCode()).isEqualTo(200);
+	}
+
+}
+----
+
+Notice that for the contract that has the `name` field the generated test method is named
+`validate_should_post_a_user`. For the one that doesn't have the name it's called
+`validate_withList_1`. It corresponds to the name of the file `WithList.groovy` and the
+index of the contract in the list.
+
+The generated stubs will look like this
+
+[source]
+----
+should post a user.json
+1_WithList.json
+----
+
+As you can see the first file got the `name` parameter from the contract. The second
+got the name of the contract file `WithList.groovy` prefixed with the index (in this case
+contract had index `1` in the list of contracts in the file).
+
+TIP: As you can see it's much better if you name your contracts since then your tests
+ are far more meaningful.
+
+
+=== Customization
 
 ==== Extending the DSL
 

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

@@ -138,7 +138,7 @@ contracts {
     contractsWorkOffline = false
 }
 
-tasks.create(type: Jar, name: 'verifierStubsJar', dependsOn: 'generateWireMockClientStubs') {
+tasks.create(type: Jar, name: 'verifierStubsJar', dependsOn: 'convert') {
     baseName = project.name
     classifier = contracts.stubsSuffix
     from contractVerifier.stubsOutputDir
@@ -265,7 +265,7 @@ In consumer service you need to configure Spring Cloud Contract Verifier plugin
 
 [source,bash,indent=0]
 ----
-./gradlew generateWireMockClientStubs
+./gradlew generateClientStubs
 ----
 
 Note that `stubsOutputDir` option has to be set for stub generation to work.