diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index ca450b463f..1056df527e 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -280,7 +280,7 @@ of the JAR containing the contracts:

<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
-		<stubsMode>REMOTE</stubsMode>
+		<contractsMode>REMOTE</contractsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
diff --git a/multi/multi__spring_cloud_contract_stub_runner.html b/multi/multi__spring_cloud_contract_stub_runner.html
index 9c6fca8211..85b226a31e 100644
--- a/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/multi/multi__spring_cloud_contract_stub_runner.html
@@ -688,12 +688,12 @@ would like the Stub Runner to take into consideration. You can read more about t
 Aether versioning
 ranges here.
6.9 Stub Runner Docker
We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image
 that will start the standalone version of Stub Runner.
If you want to learn more about the basics of Maven, artifact ids,
-group ids, classifiers and Artifact Managers, just click here Section 4.5, “Docker Project”.
6.9.1 How to use it
Just execute the docker image. You can pass any of the Section 6.8.1, “Common Properties for JUnit and Spring”
+group ids, classifiers and Artifact Managers, just click here Section 4.6, “Docker Project”.
6.9.1 How to use it
Just execute the docker image. You can pass any of the Section 6.8.1, “Common Properties for JUnit and Spring”
 as environment variables. The convention is that all the
 letters should be upper case. The camel case notation should
 and the dot (.) should be separated via underscore (_). E.g.
  the stubrunner.repositoryRoot property should be represented
-  as a STUBRUNNER_REPOSITORY_ROOT environment variable.
6.9.2 Example of client side usage in a non JVM project
We’d like to use the stubs created in this Section 4.5.4, “Server side (nodejs)” step.
+  as a STUBRUNNER_REPOSITORY_ROOT environment variable.
6.9.2 Example of client side usage in a non JVM project
We’d like to use the stubs created in this Section 4.6.4, “Server side (nodejs)” step.
 Let’s assume that we want to run the stubs on port 9876. The NodeJS code
 is available here:
$ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
 $ cd bookstore
Let’s run the Stub Runner Boot application with the stubs.
# Provide the Spring Cloud Contract Docker version
diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html
index 3d266193d4..6a4e5294a2 100644
--- a/multi/multi__spring_cloud_contract_verifier_setup.html
+++ b/multi/multi__spring_cloud_contract_verifier_setup.html
@@ -1,6 +1,6 @@
 
       
-   4. Spring Cloud Contract Verifier Setup
4. Spring Cloud Contract Verifier Setup
Prev   Next
4. Spring Cloud Contract Verifier Setup
You can set up Spring Cloud Contract Verifier in the following ways:
4.1 Gradle Project
To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the
+   4. Spring Cloud Contract Verifier Setup
4. Spring Cloud Contract Verifier Setup
Prev   Next
4. Spring Cloud Contract Verifier Setup
You can set up Spring Cloud Contract Verifier in the following ways:
4.1 Gradle Project
To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the
 following sections:
4.1.1 Prerequisites
In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a
 Gradle or a Maven plugin.
[Warning]Warning
If you want to use Spock in your projects, you must add separately the
 spock-core and spock-spring modules. Check Spock
@@ -141,9 +141,10 @@ closure to set it up.
 * contractsPath: Specifies the path to the jar. If contract dependencies are
  downloaded, the path defaults to groupid/artifactid where groupid is slash
  separated. Otherwise, it scans contracts under the provided directory.
-* contractsWorkOffline: Specifies whether to download the dependencies each time, so
-that you can work online. In other words, it specifies whether to reuses the local Maven
-repo.
4.1.10 Single Base Class for All Tests
When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
+* contractsMode: Specifies the mode of downloading contracts (whether the
+JAR is available offline, remotely etc.)
+* contractsSnapshotCheckSkip: If set to true will not assert whether the
+downloaded stubs / contract JAR was downloaded from a remote location or a local one
4.1.10 Single Base Class for All Tests
When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
 specification for all generated acceptance tests. In this class, you need to point to an
 endpoint, which should be verified.
abstract class BaseMockMvcSpec extends Specification {
 
@@ -206,7 +207,7 @@ WireMock JSON stubs using:
./gradlew generateClie
  }
 }
LoanApplication makes a call to FraudDetection service. This request is handled by a
 WireMock server configured with stubs generated by Spring Cloud Contract Verifier.
4.2 Maven Project
To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the
-following sections:
4.2.1 Add maven plugin
Add the Spring Cloud Contract BOM in a fashion similar to this:
<dependencyManagement>
+following sections:
4.2.1 Add maven plugin
Add the Spring Cloud Contract BOM in a fashion similar to this:
<dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -374,8 +375,8 @@ the matched contract. For example, if you have a contract under
 extends com.example.base.BaseClass. This setting takes precedence over
 packageWithBaseClasses and baseClassForTests.
If you want to download your contract definitions from a Maven repository, you can use
 the following options:
  • contractDependency: The contract dependency that contains all the packaged contracts.
  • contractsPath: The path to the concrete contracts in the JAR with packaged contracts.
-Defaults to groupid/artifactid where gropuid is slash separated.
  • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the
-local Maven artifacts should be reused.
  • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided,
+Defaults to groupid/artifactid where gropuid is slash separated.
  • contractsMode: Picks the mode in which stubs will be found and registered
  • contractsSnapshotCheckSkip: If true then will not assert whether a stub / contract
+JAR was downloaded from local or remote location
  • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided,
 use the current Maven ones.
  • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
  • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
  • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
  • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.
We cache only non-snapshot, explicitly provided versions (for example
 + or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.
4.2.8 Single Base Class for All Tests
When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
 specification for all generated acceptance tests. In this class, you need to point to an
@@ -492,48 +493,7 @@ goal.
For Groovy Spock code, use the following:
</plugin>
         </plugins>
     </pluginManagement>
-</build>
4.2.12 Spring Cloud Contract Verifier on the Consumer Side
You can also use the Spring Cloud Contract Verifier for the consumer side. To do so, use
-the plugin so that it only converts the contracts and generates the stubs. To achieve
-that, you need to configure Spring Cloud Contract Verifier plugin in exactly the same way
-as you would for a provider. You need to copy contracts stored in
-src/test/resources/contracts and generate WireMock JSON stubs using the
-mvn generateStubs command. By default, the generated WireMock mapping is stored in a
-directory named target/mappings. From these generated mappings, your project should
-create additional artifacts with a classifier of stubs for easy deployment to the maven
-repository.
Here is a sample configuration:
<plugin>
-    <groupId>org.springframework.cloud</groupId>
-    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
-    <version>${verifier-plugin.version}</version>
-    <executions>
-        <execution>
-            <goals>
-                <goal>convert</goal>
-                <goal>generateStubs</goal>
-            </goals>
-        </execution>
-    </executions>
-</plugin>
When present, JSON stubs can be used in consumer automated tests, as shown here:
@RunWith(SpringTestRunner.class)
-@SpringBootTest
-@AutoConfigureStubRunner
-public class LoanApplicationServiceTests {
-
-  @Autowired
-  LoanApplicationService service;
-
-  @Test
-  public void shouldSuccessfullyApplyForLoan() {
-    //given:
- 	LoanApplication application =
-			new LoanApplication(new Client("12345678901"), 123.123);
-    //when:
-	LoanApplicationResult loanApplication = service.loanApplication(application);
-    // then:
-	assertThat(loanApplication.loanApplicationStatus).isEqualTo(LoanApplicationStatus.LOAN_APPLIED);
-	assertThat(loanApplication.rejectionReason).isNull();
-  }
-}
LoanApplication makes a call to the FraudDetection service. This request is handled
-by a WireMock server configured with stubs generated by the Spring Cloud Contract
-Verifier.
4.3 Stubs and Transitive Dependencies
The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One
+</build>
4.3 Stubs and Transitive Dependencies
The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One
 problem that arises is that, when reusing the stubs, you can mistakenly import all of
 that stub’s dependencies. When building a Maven artifact, even though you have a couple
 of different jars, all of them share one pom:
├── github-webhook-0.0.1.BUILD-20160903.075506-1-stubs.jar
@@ -550,7 +510,15 @@ when you include the github-webhook stubs in anothe
 dependency gets downloaded by Stub Runner) then, since all of the dependencies are
 optional, they will not get downloaded.
Create a separate artifactid for the stubs
If you create a separate artifactid, then you can set it up in whatever way you wish.
 For example, you might decide to have no dependencies at all.
Exclude dependencies on the consumer side
As a consumer, if you add the stub dependency to your classpath, you can explicitly
-exclude the unwanted dependencies.
4.4 Scenarios
You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
+exclude the unwanted dependencies.
4.4 CI Server setup
When fetching stubs / contracts in a CI, shared environment, what might happen is that
+both the producer and the consumer reuse the same local Maven repository. Due to this,
+the framework, responsible for downloading a stub JAR from remote location,
+can’t decide which JAR should be picked, local or remote one. That caused
+the "The artifact was found in the local repository but you have explicitly
+stated that it should be downloaded from a remote one" exception
+and failed the build.
For such cases we’re introducing the property and plugin setup mechanism:
  • via stubrunner.snapshot-check-skip system property
  • via STUBRUNNER_SNAPSHOT_CHECK_SKIP environment variable
if either of these values is set to true, then the stub downloader will not
+verify the origin of the downloaded JAR.
For the plugins you need to set the contractsSnapshotSkipCheck property
+to true.
4.5 Scenarios
You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
 stick to the proper naming convention while creating your contracts. The convention
 requires including an order number followed by an underscore. This will work regardles
  of whether you’re working with YAML or Groovy. Example:
my_contracts_dir\
@@ -559,10 +527,10 @@ requires including an order number followed by an underscore. This will work reg
     2_showCart.groovy
     3_logout.groovy
Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a
 name of scenario1 and the three following steps:
  1. login marked as Started pointing to…​
  2. showCart marked as Step1 pointing to…​
  3. logout marked as Step2 which will close the scenario.
More details about WireMock scenarios can be found at
-http://wiremock.org/stateful-behaviour.html
Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
4.5 Docker Project
We’re publishing a springcloud/spring-cloud-contract Docker image
+http://wiremock.org/stateful-behaviour.html
Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
4.6 Docker Project
We’re publishing a springcloud/spring-cloud-contract Docker image
 that contains a project that will generate tests and execute them in EXPLICIT mode
 against a running application.
[Tip]Tip
The EXPLICIT mode means that the tests generated from contracts will send
-real requests and not the mocked ones.
4.5.1 Short intro to Maven, JARs and Binary storage
Since the Docker image can be used by non JVM projects, it’s good to
+real requests and not the mocked ones.
4.6.1 Short intro to Maven, JARs and Binary storage
Since the Docker image can be used by non JVM projects, it’s good to
 explain the basic terms behind Spring Cloud Contract packaging defaults.
Part of the following definitions were taken from the Maven Glossary
  • Project: Maven thinks in terms of projects. Everything that you
 will build are projects. Those projects follow a well defined
 “Project Object Model”. Projects can depend on other projects,
@@ -589,7 +557,7 @@ like them to be available for others to download / reference or reuse. In case
 of the JVM world those artifacts would be JARs, for Ruby these are gems
 and for Docker those would be Docker images. You can store those artifacts
 in a manager. Examples of such managers can be Artifactory
-or Nexus.
4.5.2 How it works
The image searches for contracts under the /contracts folder.
+or Nexus.
4.6.2 How it works
The image searches for contracts under the /contracts folder.
 The output from running the tests will be available under
 /spring-cloud-contract/build folder (it’s useful for debugging
 purposes).
It’s enough for you to mount your contracts, pass the environment variables
@@ -597,8 +565,8 @@ purposes).
It’s enough for you to mount your contracts, pass the env
 your running application, to the Artifact manager instance etc.
  • PROJECT_GROUP - your project’s group id. Defaults to com.example.
  • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
  • PROJECT_NAME - artifact id. Defaults to example
  • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local
 which is the default URL of Artifactory running locally
  • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
  • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
  • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.
These environment variables are used when tests are executed:
  • APPLICATION_BASE_URL - url against which tests should be executed.
 Remember that it has to be accessible from the Docker container (e.g. localhost
-will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application
4.5.3 Example of usage
Let’s take a look at a simple MVC application
$ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
-$ cd bookstore
The contracts are available under /contracts folder.
4.5.4 Server side (nodejs)
Since we want to run tests, we could just execute:
$ npm test
however, for learning purposes, let’s split it into pieces:
# Stop docker infra (nodejs, artifactory)
+will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application
    • 4.6.3 Example of usage
    Let’s take a look at a simple MVC application
    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
+$ cd bookstore
    The contracts are available under /contracts folder.
    4.6.4 Server side (nodejs)
    Since we want to run tests, we could just execute:
    $ npm test
    however, for learning purposes, let’s split it into pieces:
    # Stop docker infra (nodejs, artifactory)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html
index 80063b220c..ab857d4848 100644
--- a/multi/multi_spring-cloud-contract.html
+++ b/multi/multi_spring-cloud-contract.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Contract
    Spring Cloud Contract
       Next
    Spring Cloud Contract
    Table of Contents
    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. I don’t want to write a contract in Groovy!
    3.3. What is this value(consumer(), producer()) ?
    3.4. How to do Stubs versioning?
    3.4.1. API Versioning
    3.4.2. JAR versioning
    3.4.3. Dev or prod stubs
    3.5. Common repo with contracts
    3.5.1. Repo structure
    3.5.2. Workflow
    3.5.3. Consumer
    3.5.4. Producer
    3.6. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    4.5. Docker Project
    4.5.1. Short intro to Maven, JARs and Binary storage
    4.5.2. How it works
    Environment Variables
    4.5.3. Example of usage
    4.5.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    Spring Cloud CLI
    6.6.2. Endpoints
    HTTP
    Messaging
    6.6.3. Example
    6.6.4. Stub Runner Boot with Service Discovery
    6.7. Stubs Per Consumer
    6.8. Common
    6.8.1. Common Properties for JUnit and Spring
    6.8.2. Stub Runner Stubs IDs
    6.9. Stub Runner Docker
    6.9.1. How to use it
    6.9.2. Example of client side usage in a non JVM project
    7. Stub Runner for Messaging
    7.1. Stub triggering
    7.1.1. Trigger by Label
    7.1.2. Trigger by Group and Artifact Ids
    7.1.3. Trigger by Artifact Ids
    7.1.4. Trigger All Messages
    7.2. Stub Runner Integration
    7.2.1. Adding the Runner to the Project
    7.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.3. Stub Runner Stream
    7.3.1. Adding the Runner to the Project
    7.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.4. Stub Runner Spring AMQP
    7.4.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    8. Contract DSL
    8.1. Limitations
    8.2. Common Top-Level elements
    8.2.1. Description
    8.2.2. Name
    8.2.3. Ignoring Contracts
    8.2.4. Passing Values from Files
    8.2.5. HTTP Top-Level Elements
    8.3. Request
    8.4. Response
    8.5. Dynamic properties
    8.5.1. Dynamic properties inside the body
    8.5.2. Regular expressions
    8.5.3. Passing Optional Parameters
    8.5.4. Executing Custom Methods on the Server Side
    8.5.5. Referencing the Request from the Response
    8.5.6. Registering Your Own WireMock Extension
    8.5.7. Dynamic Properties in the Matchers Sections
    8.6. JAX-RS Support
    8.7. Async Support
    8.8. Working with Context Paths
    8.9. Messaging Top-Level Elements
    8.9.1. Output Triggered by a Method
    8.9.2. Output Triggered by a Message
    8.9.3. Consumer/Producer
    8.9.4. Common
    8.10. Multiple Contracts in One File
    9. Customization
    9.1. Extending the DSL
    9.1.1. Common JAR
    9.1.2. Adding the Dependency to the Project
    9.1.3. Test the Dependency in the Project’s Dependencies
    9.1.4. Test a Dependency in the Plugin’s Dependencies
    9.1.5. Referencing classes in DSLs
    10. Using the Pluggable Architecture
    10.1. Custom Contract Converter
    10.1.1. Pact Converter
    10.1.2. Pact Contract
    10.1.3. Pact for Producers
    10.1.4. Pact for Consumers
    10.2. Using the Custom Test Generator
    10.3. Using the Custom Stub Generator
    10.4. Using the Custom Stub Runner
    10.5. Using the Custom Stub Downloader
    11. Spring Cloud Contract WireMock
    11.1. Registering Stubs Automatically
    11.2. Using Files to Specify the Stub Bodies
    11.3. Alternative: Using JUnit Rules
    11.4. Relaxed SSL Validation for Rest Template
    11.5. WireMock and Spring MVC Mocks
    11.6. Customization of WireMock configuration
    11.7. Generating Stubs using REST Docs
    11.8. Generating Contracts by Using REST Docs
    12. Migrations
    12.1. 1.0.x → 1.1.x
    12.1.1. New structure of generated stubs
    12.2. 1.1.x → 1.2.x
    12.2.1. Custom HttpServerStub
    12.2.2. New packages for generated tests
    12.2.3. New Methods in TemplateProcessor
    12.2.4. RestAssured 3.0
    12.3. 1.2.x → 2.0.x
    12.3.1. No Camel support
    13. Links
       Next
       
    
\ No newline at end of file
+   Spring Cloud Contract
    Spring Cloud Contract
       Next
    Spring Cloud Contract
    Table of Contents
    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. I don’t want to write a contract in Groovy!
    3.3. What is this value(consumer(), producer()) ?
    3.4. How to do Stubs versioning?
    3.4.1. API Versioning
    3.4.2. JAR versioning
    3.4.3. Dev or prod stubs
    3.5. Common repo with contracts
    3.5.1. Repo structure
    3.5.2. Workflow
    3.5.3. Consumer
    3.5.4. Producer
    3.6. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.3. Stubs and Transitive Dependencies
    4.4. CI Server setup
    4.5. Scenarios
    4.6. Docker Project
    4.6.1. Short intro to Maven, JARs and Binary storage
    4.6.2. How it works
    Environment Variables
    4.6.3. Example of usage
    4.6.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    Spring Cloud CLI
    6.6.2. Endpoints
    HTTP
    Messaging
    6.6.3. Example
    6.6.4. Stub Runner Boot with Service Discovery
    6.7. Stubs Per Consumer
    6.8. Common
    6.8.1. Common Properties for JUnit and Spring
    6.8.2. Stub Runner Stubs IDs
    6.9. Stub Runner Docker
    6.9.1. How to use it
    6.9.2. Example of client side usage in a non JVM project
    7. Stub Runner for Messaging
    7.1. Stub triggering
    7.1.1. Trigger by Label
    7.1.2. Trigger by Group and Artifact Ids
    7.1.3. Trigger by Artifact Ids
    7.1.4. Trigger All Messages
    7.2. Stub Runner Integration
    7.2.1. Adding the Runner to the Project
    7.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.3. Stub Runner Stream
    7.3.1. Adding the Runner to the Project
    7.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.4. Stub Runner Spring AMQP
    7.4.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    8. Contract DSL
    8.1. Limitations
    8.2. Common Top-Level elements
    8.2.1. Description
    8.2.2. Name
    8.2.3. Ignoring Contracts
    8.2.4. Passing Values from Files
    8.2.5. HTTP Top-Level Elements
    8.3. Request
    8.4. Response
    8.5. Dynamic properties
    8.5.1. Dynamic properties inside the body
    8.5.2. Regular expressions
    8.5.3. Passing Optional Parameters
    8.5.4. Executing Custom Methods on the Server Side
    8.5.5. Referencing the Request from the Response
    8.5.6. Registering Your Own WireMock Extension
    8.5.7. Dynamic Properties in the Matchers Sections
    8.6. JAX-RS Support
    8.7. Async Support
    8.8. Working with Context Paths
    8.9. Messaging Top-Level Elements
    8.9.1. Output Triggered by a Method
    8.9.2. Output Triggered by a Message
    8.9.3. Consumer/Producer
    8.9.4. Common
    8.10. Multiple Contracts in One File
    9. Customization
    9.1. Extending the DSL
    9.1.1. Common JAR
    9.1.2. Adding the Dependency to the Project
    9.1.3. Test the Dependency in the Project’s Dependencies
    9.1.4. Test a Dependency in the Plugin’s Dependencies
    9.1.5. Referencing classes in DSLs
    10. Using the Pluggable Architecture
    10.1. Custom Contract Converter
    10.1.1. Pact Converter
    10.1.2. Pact Contract
    10.1.3. Pact for Producers
    10.1.4. Pact for Consumers
    10.2. Using the Custom Test Generator
    10.3. Using the Custom Stub Generator
    10.4. Using the Custom Stub Runner
    10.5. Using the Custom Stub Downloader
    11. Spring Cloud Contract WireMock
    11.1. Registering Stubs Automatically
    11.2. Using Files to Specify the Stub Bodies
    11.3. Alternative: Using JUnit Rules
    11.4. Relaxed SSL Validation for Rest Template
    11.5. WireMock and Spring MVC Mocks
    11.6. Customization of WireMock configuration
    11.7. Generating Stubs using REST Docs
    11.8. Generating Contracts by Using REST Docs
    12. Migrations
    12.1. 1.0.x → 1.1.x
    12.1.1. New structure of generated stubs
    12.2. 1.1.x → 1.2.x
    12.2.1. Custom HttpServerStub
    12.2.2. New packages for generated tests
    12.2.3. New Methods in TemplateProcessor
    12.2.4. RestAssured 3.0
    12.3. 1.2.x → 2.0.x
    12.3.1. No Camel support
    13. Links
       Next
       
    
\ No newline at end of file
diff --git a/single/spring-cloud-contract.html b/single/spring-cloud-contract.html
index befc981903..bd74599698 100644
--- a/single/spring-cloud-contract.html
+++ b/single/spring-cloud-contract.html
@@ -1,6 +1,6 @@
 
       
-   Spring Cloud Contract
    Spring Cloud Contract
    Table of Contents
    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. I don’t want to write a contract in Groovy!
    3.3. What is this value(consumer(), producer()) ?
    3.4. How to do Stubs versioning?
    3.4.1. API Versioning
    3.4.2. JAR versioning
    3.4.3. Dev or prod stubs
    3.5. Common repo with contracts
    3.5.1. Repo structure
    3.5.2. Workflow
    3.5.3. Consumer
    3.5.4. Producer
    3.6. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.2.12. Spring Cloud Contract Verifier on the Consumer Side
    4.3. Stubs and Transitive Dependencies
    4.4. Scenarios
    4.5. Docker Project
    4.5.1. Short intro to Maven, JARs and Binary storage
    4.5.2. How it works
    Environment Variables
    4.5.3. Example of usage
    4.5.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    Spring Cloud CLI
    6.6.2. Endpoints
    HTTP
    Messaging
    6.6.3. Example
    6.6.4. Stub Runner Boot with Service Discovery
    6.7. Stubs Per Consumer
    6.8. Common
    6.8.1. Common Properties for JUnit and Spring
    6.8.2. Stub Runner Stubs IDs
    6.9. Stub Runner Docker
    6.9.1. How to use it
    6.9.2. Example of client side usage in a non JVM project
    7. Stub Runner for Messaging
    7.1. Stub triggering
    7.1.1. Trigger by Label
    7.1.2. Trigger by Group and Artifact Ids
    7.1.3. Trigger by Artifact Ids
    7.1.4. Trigger All Messages
    7.2. Stub Runner Integration
    7.2.1. Adding the Runner to the Project
    7.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.3. Stub Runner Stream
    7.3.1. Adding the Runner to the Project
    7.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.4. Stub Runner Spring AMQP
    7.4.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    8. Contract DSL
    8.1. Limitations
    8.2. Common Top-Level elements
    8.2.1. Description
    8.2.2. Name
    8.2.3. Ignoring Contracts
    8.2.4. Passing Values from Files
    8.2.5. HTTP Top-Level Elements
    8.3. Request
    8.4. Response
    8.5. Dynamic properties
    8.5.1. Dynamic properties inside the body
    8.5.2. Regular expressions
    8.5.3. Passing Optional Parameters
    8.5.4. Executing Custom Methods on the Server Side
    8.5.5. Referencing the Request from the Response
    8.5.6. Registering Your Own WireMock Extension
    8.5.7. Dynamic Properties in the Matchers Sections
    8.6. JAX-RS Support
    8.7. Async Support
    8.8. Working with Context Paths
    8.9. Messaging Top-Level Elements
    8.9.1. Output Triggered by a Method
    8.9.2. Output Triggered by a Message
    8.9.3. Consumer/Producer
    8.9.4. Common
    8.10. Multiple Contracts in One File
    9. Customization
    9.1. Extending the DSL
    9.1.1. Common JAR
    9.1.2. Adding the Dependency to the Project
    9.1.3. Test the Dependency in the Project’s Dependencies
    9.1.4. Test a Dependency in the Plugin’s Dependencies
    9.1.5. Referencing classes in DSLs
    10. Using the Pluggable Architecture
    10.1. Custom Contract Converter
    10.1.1. Pact Converter
    10.1.2. Pact Contract
    10.1.3. Pact for Producers
    10.1.4. Pact for Consumers
    10.2. Using the Custom Test Generator
    10.3. Using the Custom Stub Generator
    10.4. Using the Custom Stub Runner
    10.5. Using the Custom Stub Downloader
    11. Spring Cloud Contract WireMock
    11.1. Registering Stubs Automatically
    11.2. Using Files to Specify the Stub Bodies
    11.3. Alternative: Using JUnit Rules
    11.4. Relaxed SSL Validation for Rest Template
    11.5. WireMock and Spring MVC Mocks
    11.6. Customization of WireMock configuration
    11.7. Generating Stubs using REST Docs
    11.8. Generating Contracts by Using REST Docs
    12. Migrations
    12.1. 1.0.x → 1.1.x
    12.1.1. New structure of generated stubs
    12.2. 1.1.x → 1.2.x
    12.2.1. Custom HttpServerStub
    12.2.2. New packages for generated tests
    12.2.3. New Methods in TemplateProcessor
    12.2.4. RestAssured 3.0
    12.3. 1.2.x → 2.0.x
    12.3.1. No Camel support
    13. Links
    _Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak,
+   Spring Cloud Contract
    Spring Cloud Contract
    Table of Contents
    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. Defining the contract
    2.3.2. Client Side
    2.3.3. Server Side
    2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.4.1. Technical note
    2.4.2. Consumer side (Loan Issuance)
    2.4.3. Producer side (Fraud Detection server)
    2.4.4. Consumer Side (Loan Issuance) Final Step
    2.5. Dependencies
    2.6. Additional Links
    2.6.1. Spring Cloud Contract video
    2.6.2. Readings
    2.7. Samples
    3. Spring Cloud Contract FAQ
    3.1. Why use Spring Cloud Contract Verifier and not X ?
    3.2. I don’t want to write a contract in Groovy!
    3.3. What is this value(consumer(), producer()) ?
    3.4. How to do Stubs versioning?
    3.4.1. API Versioning
    3.4.2. JAR versioning
    3.4.3. Dev or prod stubs
    3.5. Common repo with contracts
    3.5.1. Repo structure
    3.5.2. Workflow
    3.5.3. Consumer
    3.5.4. Producer
    3.6. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.3. Stubs and Transitive Dependencies
    4.4. CI Server setup
    4.5. Scenarios
    4.6. Docker Project
    4.6.1. Short intro to Maven, JARs and Binary storage
    4.6.2. How it works
    Environment Variables
    4.6.3. Example of usage
    4.6.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    Spring Cloud CLI
    6.6.2. Endpoints
    HTTP
    Messaging
    6.6.3. Example
    6.6.4. Stub Runner Boot with Service Discovery
    6.7. Stubs Per Consumer
    6.8. Common
    6.8.1. Common Properties for JUnit and Spring
    6.8.2. Stub Runner Stubs IDs
    6.9. Stub Runner Docker
    6.9.1. How to use it
    6.9.2. Example of client side usage in a non JVM project
    7. Stub Runner for Messaging
    7.1. Stub triggering
    7.1.1. Trigger by Label
    7.1.2. Trigger by Group and Artifact Ids
    7.1.3. Trigger by Artifact Ids
    7.1.4. Trigger All Messages
    7.2. Stub Runner Integration
    7.2.1. Adding the Runner to the Project
    7.2.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.3. Stub Runner Stream
    7.3.1. Adding the Runner to the Project
    7.3.2. Disabling the functionality
    Scenario 1 (no input message)
    Scenario 2 (output triggered by input)
    Scenario 3 (input with no output)
    7.4. Stub Runner Spring AMQP
    7.4.1. Adding the Runner to the Project
    Triggering the message
    Spring AMQP Test Configuration
    8. Contract DSL
    8.1. Limitations
    8.2. Common Top-Level elements
    8.2.1. Description
    8.2.2. Name
    8.2.3. Ignoring Contracts
    8.2.4. Passing Values from Files
    8.2.5. HTTP Top-Level Elements
    8.3. Request
    8.4. Response
    8.5. Dynamic properties
    8.5.1. Dynamic properties inside the body
    8.5.2. Regular expressions
    8.5.3. Passing Optional Parameters
    8.5.4. Executing Custom Methods on the Server Side
    8.5.5. Referencing the Request from the Response
    8.5.6. Registering Your Own WireMock Extension
    8.5.7. Dynamic Properties in the Matchers Sections
    8.6. JAX-RS Support
    8.7. Async Support
    8.8. Working with Context Paths
    8.9. Messaging Top-Level Elements
    8.9.1. Output Triggered by a Method
    8.9.2. Output Triggered by a Message
    8.9.3. Consumer/Producer
    8.9.4. Common
    8.10. Multiple Contracts in One File
    9. Customization
    9.1. Extending the DSL
    9.1.1. Common JAR
    9.1.2. Adding the Dependency to the Project
    9.1.3. Test the Dependency in the Project’s Dependencies
    9.1.4. Test a Dependency in the Plugin’s Dependencies
    9.1.5. Referencing classes in DSLs
    10. Using the Pluggable Architecture
    10.1. Custom Contract Converter
    10.1.1. Pact Converter
    10.1.2. Pact Contract
    10.1.3. Pact for Producers
    10.1.4. Pact for Consumers
    10.2. Using the Custom Test Generator
    10.3. Using the Custom Stub Generator
    10.4. Using the Custom Stub Runner
    10.5. Using the Custom Stub Downloader
    11. Spring Cloud Contract WireMock
    11.1. Registering Stubs Automatically
    11.2. Using Files to Specify the Stub Bodies
    11.3. Alternative: Using JUnit Rules
    11.4. Relaxed SSL Validation for Rest Template
    11.5. WireMock and Spring MVC Mocks
    11.6. Customization of WireMock configuration
    11.7. Generating Stubs using REST Docs
    11.8. Generating Contracts by Using REST Docs
    12. Migrations
    12.1. 1.0.x → 1.1.x
    12.1.1. New structure of generated stubs
    12.2. 1.1.x → 1.2.x
    12.2.1. Custom HttpServerStub
    12.2.2. New packages for generated tests
    12.2.3. New Methods in TemplateProcessor
    12.2.4. RestAssured 3.0
    12.3. 1.2.x → 2.0.x
    12.3.1. No Camel support
    13. Links
    _Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak,
 Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant
    2.0.0.BUILD-SNAPSHOT
    1. Spring Cloud Contract
    You need confidence when pushing new features to a new application or service in a
 distributed system. This project provides support for Consumer Driven Contracts and
 service schemas in Spring applications (for both HTTP and message-based interactions),
@@ -845,7 +845,7 @@ of the JAR containing the contracts:
    <groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
-		<stubsMode>REMOTE</stubsMode>
+		<contractsMode>REMOTE</contractsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
@@ -865,7 +865,7 @@ to dump all mappings per artifact id. Also the port at which the given stub serv
 started will be attached.
    3.7.3 Can I reference the request from the response?
    Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support
 for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.
    3.7.4 Can I reference text from file?
    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the
 DSL and provide a path relative to where the contract lays.
-If you’re using YAML just use the bodyFromFile property.
    4. Spring Cloud Contract Verifier Setup
    You can set up Spring Cloud Contract Verifier in the following ways:
    4.1 Gradle Project
    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the
+If you’re using YAML just use the bodyFromFile property.
    4. Spring Cloud Contract Verifier Setup
    You can set up Spring Cloud Contract Verifier in the following ways:
    4.1 Gradle Project
    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the
 following sections:
    4.1.1 Prerequisites
    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a
 Gradle or a Maven plugin.
    [Warning]Warning
    If you want to use Spock in your projects, you must add separately the
 spock-core and spock-spring modules. Check Spock
@@ -1006,9 +1006,10 @@ closure to set it up.
 * contractsPath: Specifies the path to the jar. If contract dependencies are
  downloaded, the path defaults to groupid/artifactid where groupid is slash
  separated. Otherwise, it scans contracts under the provided directory.
-* contractsWorkOffline: Specifies whether to download the dependencies each time, so
-that you can work online. In other words, it specifies whether to reuses the local Maven
-repo.
    4.1.10 Single Base Class for All Tests
    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
+* contractsMode: Specifies the mode of downloading contracts (whether the
+JAR is available offline, remotely etc.)
+* contractsSnapshotCheckSkip: If set to true will not assert whether the
+downloaded stubs / contract JAR was downloaded from a remote location or a local one
    4.1.10 Single Base Class for All Tests
    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
 specification for all generated acceptance tests. In this class, you need to point to an
 endpoint, which should be verified.
    abstract class BaseMockMvcSpec extends Specification {
 
@@ -1071,7 +1072,7 @@ WireMock JSON stubs using:
    ./gradlew generateClie
  }
 }
    LoanApplication makes a call to FraudDetection service. This request is handled by a
 WireMock server configured with stubs generated by Spring Cloud Contract Verifier.
    4.2 Maven Project
    To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the
-following sections:
    4.2.1 Add maven plugin
    Add the Spring Cloud Contract BOM in a fashion similar to this:
    <dependencyManagement>
+following sections:
    4.2.1 Add maven plugin
    Add the Spring Cloud Contract BOM in a fashion similar to this:
    <dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -1239,8 +1240,8 @@ the matched contract. For example, if you have a contract under
 extends com.example.base.BaseClass. This setting takes precedence over
 packageWithBaseClasses and baseClassForTests.
    If you want to download your contract definitions from a Maven repository, you can use
 the following options:
    • contractDependency: The contract dependency that contains all the packaged contracts.
    • contractsPath: The path to the concrete contracts in the JAR with packaged contracts.
-Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsWorkOffline: Dictates whether the dependencies should be downloaded or the
-local Maven artifacts should be reused.
    • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided,
+Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsMode: Picks the mode in which stubs will be found and registered
    • contractsSnapshotCheckSkip: If true then will not assert whether a stub / contract
+JAR was downloaded from local or remote location
    • contractsRepositoryUrl: URL to a repo with the artifacts that have contracts. If it is not provided,
 use the current Maven ones.
    • contractsRepositoryUsername: The user name to be used to connect to the repo with contracts.
    • contractsRepositoryPassword: The password to be used to connect to the repo with contracts.
    • contractsRepositoryProxyHost: The proxy host to be used to connect to the repo with contracts.
    • contractsRepositoryProxyPort: The proxy port to be used to connect to the repo with contracts.
    We cache only non-snapshot, explicitly provided versions (for example
 + or 1.0.0.BUILD-SNAPSHOT won’t get cached). By default, this feature is turned on.
    4.2.8 Single Base Class for All Tests
    When using Spring Cloud Contract Verifier in default MockMvc, you need to create a base
 specification for all generated acceptance tests. In this class, you need to point to an
@@ -1357,48 +1358,7 @@ goal.
    For Groovy Spock code, use the following:
    </plugin>
         </plugins>
     </pluginManagement>
-</build>
    4.2.12 Spring Cloud Contract Verifier on the Consumer Side
    You can also use the Spring Cloud Contract Verifier for the consumer side. To do so, use
-the plugin so that it only converts the contracts and generates the stubs. To achieve
-that, you need to configure Spring Cloud Contract Verifier plugin in exactly the same way
-as you would for a provider. You need to copy contracts stored in
-src/test/resources/contracts and generate WireMock JSON stubs using the
-mvn generateStubs command. By default, the generated WireMock mapping is stored in a
-directory named target/mappings. From these generated mappings, your project should
-create additional artifacts with a classifier of stubs for easy deployment to the maven
-repository.
    Here is a sample configuration:
    <plugin>
-    <groupId>org.springframework.cloud</groupId>
-    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
-    <version>${verifier-plugin.version}</version>
-    <executions>
-        <execution>
-            <goals>
-                <goal>convert</goal>
-                <goal>generateStubs</goal>
-            </goals>
-        </execution>
-    </executions>
-</plugin>
    When present, JSON stubs can be used in consumer automated tests, as shown here:
    @RunWith(SpringTestRunner.class)
-@SpringBootTest
-@AutoConfigureStubRunner
-public class LoanApplicationServiceTests {
-
-  @Autowired
-  LoanApplicationService service;
-
-  @Test
-  public void shouldSuccessfullyApplyForLoan() {
-    //given:
- 	LoanApplication application =
-			new LoanApplication(new Client("12345678901"), 123.123);
-    //when:
-	LoanApplicationResult loanApplication = service.loanApplication(application);
-    // then:
-	assertThat(loanApplication.loanApplicationStatus).isEqualTo(LoanApplicationStatus.LOAN_APPLIED);
-	assertThat(loanApplication.rejectionReason).isNull();
-  }
-}
    LoanApplication makes a call to the FraudDetection service. This request is handled
-by a WireMock server configured with stubs generated by the Spring Cloud Contract
-Verifier.
    4.3 Stubs and Transitive Dependencies
    The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One
+</build>
    4.3 Stubs and Transitive Dependencies
    The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One
 problem that arises is that, when reusing the stubs, you can mistakenly import all of
 that stub’s dependencies. When building a Maven artifact, even though you have a couple
 of different jars, all of them share one pom:
    ├── github-webhook-0.0.1.BUILD-20160903.075506-1-stubs.jar
@@ -1415,7 +1375,15 @@ when you include the github-webhook stubs in anothe
 dependency gets downloaded by Stub Runner) then, since all of the dependencies are
 optional, they will not get downloaded.
    Create a separate artifactid for the stubs
    If you create a separate artifactid, then you can set it up in whatever way you wish.
 For example, you might decide to have no dependencies at all.
    Exclude dependencies on the consumer side
    As a consumer, if you add the stub dependency to your classpath, you can explicitly
-exclude the unwanted dependencies.
    4.4 Scenarios
    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
+exclude the unwanted dependencies.
    4.4 CI Server setup
    When fetching stubs / contracts in a CI, shared environment, what might happen is that
+both the producer and the consumer reuse the same local Maven repository. Due to this,
+the framework, responsible for downloading a stub JAR from remote location,
+can’t decide which JAR should be picked, local or remote one. That caused
+the "The artifact was found in the local repository but you have explicitly
+stated that it should be downloaded from a remote one" exception
+and failed the build.
    For such cases we’re introducing the property and plugin setup mechanism:
    • via stubrunner.snapshot-check-skip system property
    • via STUBRUNNER_SNAPSHOT_CHECK_SKIP environment variable
    if either of these values is set to true, then the stub downloader will not
+verify the origin of the downloaded JAR.
    For the plugins you need to set the contractsSnapshotSkipCheck property
+to true.
    4.5 Scenarios
    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
 stick to the proper naming convention while creating your contracts. The convention
 requires including an order number followed by an underscore. This will work regardles
  of whether you’re working with YAML or Groovy. Example:
    my_contracts_dir\
@@ -1424,10 +1392,10 @@ requires including an order number followed by an underscore. This will work reg
     2_showCart.groovy
     3_logout.groovy
    Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a
 name of scenario1 and the three following steps:
    1. login marked as Started pointing to…​
    2. showCart marked as Step1 pointing to…​
    3. logout marked as Step2 which will close the scenario.
    More details about WireMock scenarios can be found at
-http://wiremock.org/stateful-behaviour.html
    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
    4.5 Docker Project
    We’re publishing a springcloud/spring-cloud-contract Docker image
+http://wiremock.org/stateful-behaviour.html
    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
    4.6 Docker Project
    We’re publishing a springcloud/spring-cloud-contract Docker image
 that contains a project that will generate tests and execute them in EXPLICIT mode
 against a running application.
    [Tip]Tip
    The EXPLICIT mode means that the tests generated from contracts will send
-real requests and not the mocked ones.
    4.5.1 Short intro to Maven, JARs and Binary storage
    Since the Docker image can be used by non JVM projects, it’s good to
+real requests and not the mocked ones.
    4.6.1 Short intro to Maven, JARs and Binary storage
    Since the Docker image can be used by non JVM projects, it’s good to
 explain the basic terms behind Spring Cloud Contract packaging defaults.
    Part of the following definitions were taken from the Maven Glossary
    • Project: Maven thinks in terms of projects. Everything that you
 will build are projects. Those projects follow a well defined
 “Project Object Model”. Projects can depend on other projects,
@@ -1454,7 +1422,7 @@ like them to be available for others to download / reference or reuse. In case
 of the JVM world those artifacts would be JARs, for Ruby these are gems
 and for Docker those would be Docker images. You can store those artifacts
 in a manager. Examples of such managers can be Artifactory
-or Nexus.
    4.5.2 How it works
    The image searches for contracts under the /contracts folder.
+or Nexus.
    4.6.2 How it works
    The image searches for contracts under the /contracts folder.
 The output from running the tests will be available under
 /spring-cloud-contract/build folder (it’s useful for debugging
 purposes).
    It’s enough for you to mount your contracts, pass the environment variables
@@ -1462,8 +1430,8 @@ purposes).
    It’s enough for you to mount your contracts, pass the env
 your running application, to the Artifact manager instance etc.
    • PROJECT_GROUP - your project’s group id. Defaults to com.example.
    • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
    • PROJECT_NAME - artifact id. Defaults to example
    • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local
 which is the default URL of Artifactory running locally
    • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
    • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
    • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.
    These environment variables are used when tests are executed:
    • APPLICATION_BASE_URL - url against which tests should be executed.
 Remember that it has to be accessible from the Docker container (e.g. localhost
-will not work)
    • APPLICATION_USERNAME - (optional) username for basic authentication to your application
    • APPLICATION_PASSWORD - (optional) password for basic authentication to your application
    4.5.3 Example of usage
    Let’s take a look at a simple MVC application
    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
-$ cd bookstore
    The contracts are available under /contracts folder.
    4.5.4 Server side (nodejs)
    Since we want to run tests, we could just execute:
    $ npm test
    however, for learning purposes, let’s split it into pieces:
    # Stop docker infra (nodejs, artifactory)
+will not work)
  • APPLICATION_USERNAME - (optional) username for basic authentication to your application
  • APPLICATION_PASSWORD - (optional) password for basic authentication to your application
    • 4.6.3 Example of usage
    Let’s take a look at a simple MVC application
    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
+$ cd bookstore
    The contracts are available under /contracts folder.
    4.6.4 Server side (nodejs)
    Since we want to run tests, we could just execute:
    $ npm test
    however, for learning purposes, let’s split it into pieces:
    # Stop docker infra (nodejs, artifactory)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
@@ -2442,12 +2410,12 @@ would like the Stub Runner to take into consideration. You can read more about t
 Aether versioning
 ranges here.
    6.9 Stub Runner Docker
    We’re publishing a spring-cloud/spring-cloud-contract-stub-runner Docker image
 that will start the standalone version of Stub Runner.
    If you want to learn more about the basics of Maven, artifact ids,
-group ids, classifiers and Artifact Managers, just click here Section 4.5, “Docker Project”.
    6.9.1 How to use it
    Just execute the docker image. You can pass any of the Section 6.8.1, “Common Properties for JUnit and Spring”
+group ids, classifiers and Artifact Managers, just click here Section 4.6, “Docker Project”.
    6.9.1 How to use it
    Just execute the docker image. You can pass any of the Section 6.8.1, “Common Properties for JUnit and Spring”
 as environment variables. The convention is that all the
 letters should be upper case. The camel case notation should
 and the dot (.) should be separated via underscore (_). E.g.
  the stubrunner.repositoryRoot property should be represented
-  as a STUBRUNNER_REPOSITORY_ROOT environment variable.
    6.9.2 Example of client side usage in a non JVM project
    We’d like to use the stubs created in this Section 4.5.4, “Server side (nodejs)” step.
+  as a STUBRUNNER_REPOSITORY_ROOT environment variable.
    6.9.2 Example of client side usage in a non JVM project
    We’d like to use the stubs created in this Section 4.6.4, “Server side (nodejs)” step.
 Let’s assume that we want to run the stubs on port 9876. The NodeJS code
 is available here:
    $ git clone https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs
 $ cd bookstore
    Let’s run the Stub Runner Boot application with the stubs.
    # Provide the Spring Cloud Contract Docker version
diff --git a/spring-cloud-contract-maven-plugin/checkstyle.html b/spring-cloud-contract-maven-plugin/checkstyle.html
index 3fade8b6b4..d4fe9f8dc8 100644
--- a/spring-cloud-contract-maven-plugin/checkstyle.html
+++ b/spring-cloud-contract-maven-plugin/checkstyle.html
@@ -1,13 +1,13 @@
 
 
 
   
     
     
-    
+    
     
     Spring Cloud Contract Maven Plugin – Checkstyle Results
     
@@ -146,7 +146,7 @@
       
 
  • Required: No
    • 
           
 
  • Default: ${project.build.directory}/stubs/
    • 
-        
    
-
    stubsMode:
    
-        
-
    Picks the mode in which stubs will be found and registered
    
-        
-
      
-          
-
    • Type: org.springframework.cloud.contract.stubrunner.spring.StubRunnerProperties$StubsMode
      • 
-          
-
    • Required: No
      • 
-          
-
    • User Property: stubsMode
      • 
-          
-
    • Default: CLASSPATH
      • 
         
    
       
    
     
    
diff --git a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html
index d771f3c312..182d76f946 100644
--- a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html
+++ b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html
@@ -1,13 +1,13 @@
 
 
 
   
     
     
-    
+    
     
     Spring Cloud Contract Maven Plugin – spring-cloud-contract:generateStubs
     
@@ -146,7 +146,7 @@
       
           
 
  • Required: No
    • 
         
    
-
    stubsMode:
    
-        
-
    Picks the mode in which stubs will be found and registered
    
-        
-
      
-          
-
    • Type: org.springframework.cloud.contract.stubrunner.spring.StubRunnerProperties$StubsMode
      • 
-          
-
    • Required: No
      • 
-          
-
    • User Property: stubsMode
      • 
-          
-
    • Default: CLASSPATH
      • 
-        
    
 
    testFramework:
    
         
 
    (no description)
    
diff --git a/spring-cloud-contract-maven-plugin/help-mojo.html b/spring-cloud-contract-maven-plugin/help-mojo.html
index a4fc363e53..f225f7b6bc 100644
--- a/spring-cloud-contract-maven-plugin/help-mojo.html
+++ b/spring-cloud-contract-maven-plugin/help-mojo.html
@@ -1,13 +1,13 @@
 
 
 
   
     
     
-    
+    
     
     Spring Cloud Contract Maven Plugin – spring-cloud-contract:help
     
@@ -146,7 +146,7 @@