From de9e72a4e1d264ae42048f184f2b73494633b6ad Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 23 Aug 2018 12:06:57 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...ti__spring_cloud_contract_stub_runner.html | 4 +- ..._spring_cloud_contract_verifier_setup.html | 28 +++++--------- ...lti__using_the_pluggable_architecture.html | 4 +- multi/multi_spring-cloud-contract.html | 2 +- single/spring-cloud-contract.html | 38 +++++++------------ .../checkstyle.html | 6 +-- .../complex.html | 6 +-- .../configs.html | 6 +-- .../convert-mojo.html | 11 +++--- .../generateStubs-mojo.html | 6 +-- .../generateTests-mojo.html | 11 +++--- .../help-mojo.html | 6 +-- spring-cloud-contract-maven-plugin/index.html | 6 +-- .../integration.html | 6 +-- .../issue-tracking.html | 6 +-- spring-cloud-contract-maven-plugin/junit.html | 6 +-- .../license.html | 6 +-- .../plugin-info.html | 6 +-- .../plugin-management.html | 6 +-- .../plugins.html | 6 +-- .../project-info.html | 6 +-- .../project-reports.html | 6 +-- .../project-summary.html | 6 +-- .../pushStubsToScm-mojo.html | 6 +-- .../run-mojo.html | 6 +-- .../sitemap.html | 6 +-- .../source-repository.html | 6 +-- spring-cloud-contract-maven-plugin/spock.html | 6 +-- .../team-list.html | 6 +-- spring-cloud-contract-maven-plugin/usage.html | 6 +-- spring-cloud-contract.xml | 31 --------------- 31 files changed, 109 insertions(+), 158 deletions(-) diff --git a/multi/multi__spring_cloud_contract_stub_runner.html b/multi/multi__spring_cloud_contract_stub_runner.html index 3ac7f73753..f821d04835 100644 --- a/multi/multi__spring_cloud_contract_stub_runner.html +++ b/multi/multi__spring_cloud_contract_stub_runner.html @@ -707,12 +707,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.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” +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” 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.6.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.5.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 b677a642fa..da38d9dc95 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
@@ -140,8 +140,7 @@ containing the contracts:
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 {
@@ -381,8 +380,7 @@ extends com.example.base.BaseClass. This setting ta
 packageWithBaseClasses and baseClassForTests.
  • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
 components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders.
    • 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.
    • 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
    • deleteStubsAfterTest: If set to false will not remove any downloaded
+Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsMode: Picks the mode in which stubs will be found and registered
    • deleteStubsAfterTest: If set to false will not remove any downloaded
 contracts from temporary directories
    • 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
@@ -594,15 +592,7 @@ 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 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 contractsSnapshotCheckSkip property
-to true.
    4.5 Scenarios
    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
+exclude the unwanted dependencies.
    4.4 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\
@@ -611,10 +601,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/docs/stateful-behaviour/
    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
+http://wiremock.org/docs/stateful-behaviour/
    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
 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.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
+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
 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,
@@ -641,7 +631,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.6.2 How it works
    The image searches for contracts under the /contracts folder.
+or Nexus.
    4.5.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
@@ -656,8 +646,8 @@ for group id foo.bar and artifact id .m2. Mount your local .m2 as a volume available at the container’s /root/.m2 path.
 You must not set both EXTERNAL_CONTRACTS_WORK_OFFLINE and EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL.
    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.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)
+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)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html
index fb9a00cd1e..36bc274fcf 100644
--- a/multi/multi__using_the_pluggable_architecture.html
+++ b/multi/multi__using_the_pluggable_architecture.html
@@ -421,7 +421,7 @@ to clone the repository and use it as a source of contracts
 to generate tests or stubs.
    Either via environment variables, system properties, properties set
 inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
-properties
    Table 10.1. SCM Stub Downloader properties
    Type of a property
    Name of the property
    Description
    * git.branch (plugin prop)
+properties
    Table 10.1. SCM Stub Downloader properties
    Type of a property
    Name of the property
    Description
    * git.branch (plugin prop)
 
    * stubrunner.properties.git.branch (system prop)
 
    * STUBRUNNER_PROPERTIES_GIT_BRANCH (env prop)
    master
    Which branch to checkout
    * git.username (plugin prop)
 
    * stubrunner.properties.git.username (system prop)
@@ -437,7 +437,7 @@ to fetch the Pact contract definitions from the Pact Broker.
 Whatever is set after pact:// will be parsed as the Pact Broker URL.
    Either via environment variables, system properties, properties set
 inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
-properties
    Table 10.2. SCM Stub Downloader properties
    Name of a property
    Default
    Description
    * pactbroker.host (plugin prop)
+properties
    Table 10.2. SCM Stub Downloader properties
    Name of a property
    Default
    Description
    * pactbroker.host (plugin prop)
 
    * stubrunner.properties.pactbroker.host (system prop)
 
    * STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)
    Host from URL passed to repositoryRoot
    What is the URL of Pact Broker
    * pactbroker.port (plugin prop)
 
    * stubrunner.properties.pactbroker.port (system prop)
diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html
index 83e3f906f9..a39faeda28 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. History
    2.2. Why a Contract Verifier?
    2.2.1. Testing issues
    2.3. Purposes
    2.4. How It Works
    2.4.1. A Three-second Tour
    On the Producer Side
    On the Consumer Side
    2.4.2. A Three-minute Tour
    On the Producer Side
    On the Consumer Side
    2.4.3. Defining the Contract
    2.4.4. Client Side
    2.4.5. Server Side
    2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.5.1. Technical note
    2.5.2. Consumer side (Loan Issuance)
    2.5.3. Producer side (Fraud Detection server)
    2.5.4. Consumer Side (Loan Issuance) Final Step
    2.6. Dependencies
    2.7. Additional Links
    2.7.1. Spring Cloud Contract video
    2.7.2. Readings
    2.8. 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.5.5. How can I define messaging contracts per topic not per producer?
    For Maven Project
    For Gradle Project
    3.6. Do I need a Binary Storage? Can’t I use Git?
    3.6.1. Protocol convention
    3.6.2. Producer
    3.6.3. Consumer
    3.7. Can I use the Pact Broker?
    3.7.1. Pact Consumer
    3.7.2. Producer
    3.7.3. Pact Consumer (Producer Contract approach)
    3.8. How can I debug the request/response being sent by the generated tests client?
    3.8.1. How can I debug the mapping/request/response being sent by WireMock?
    3.8.2. How can I see what got registered in the HTTP server stub?
    3.8.3. 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. Pushing stubs to SCM
    4.1.14. 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. Pushing stubs to SCM
    4.2.12. 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
    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
    Stub Runner Server Fat Jar
    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. Working with Web Flux
    8.10. Messaging Top-Level Elements
    8.10.1. Output Triggered by a Method
    8.10.2. Output Triggered by a Message
    8.10.3. Consumer/Producer
    8.10.4. Common
    8.11. Multiple Contracts in One File
    8.12. Generating Spring REST Docs snippets from the contracts
    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
    10.6. Using the SCM Stub Downloader
    10.7. Using the Pact 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. History
    2.2. Why a Contract Verifier?
    2.2.1. Testing issues
    2.3. Purposes
    2.4. How It Works
    2.4.1. A Three-second Tour
    On the Producer Side
    On the Consumer Side
    2.4.2. A Three-minute Tour
    On the Producer Side
    On the Consumer Side
    2.4.3. Defining the Contract
    2.4.4. Client Side
    2.4.5. Server Side
    2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.5.1. Technical note
    2.5.2. Consumer side (Loan Issuance)
    2.5.3. Producer side (Fraud Detection server)
    2.5.4. Consumer Side (Loan Issuance) Final Step
    2.6. Dependencies
    2.7. Additional Links
    2.7.1. Spring Cloud Contract video
    2.7.2. Readings
    2.8. 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.5.5. How can I define messaging contracts per topic not per producer?
    For Maven Project
    For Gradle Project
    3.6. Do I need a Binary Storage? Can’t I use Git?
    3.6.1. Protocol convention
    3.6.2. Producer
    3.6.3. Consumer
    3.7. Can I use the Pact Broker?
    3.7.1. Pact Consumer
    3.7.2. Producer
    3.7.3. Pact Consumer (Producer Contract approach)
    3.8. How can I debug the request/response being sent by the generated tests client?
    3.8.1. How can I debug the mapping/request/response being sent by WireMock?
    3.8.2. How can I see what got registered in the HTTP server stub?
    3.8.3. 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. Pushing stubs to SCM
    4.1.14. 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. Pushing stubs to SCM
    4.2.12. Maven Plugin and STS
    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
    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
    Stub Runner Server Fat Jar
    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. Working with Web Flux
    8.10. Messaging Top-Level Elements
    8.10.1. Output Triggered by a Method
    8.10.2. Output Triggered by a Message
    8.10.3. Consumer/Producer
    8.10.4. Common
    8.11. Multiple Contracts in One File
    8.12. Generating Spring REST Docs snippets from the contracts
    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
    10.6. Using the SCM Stub Downloader
    10.7. Using the Pact 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 25a24c1ace..9c7997b6b3 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. History
    2.2. Why a Contract Verifier?
    2.2.1. Testing issues
    2.3. Purposes
    2.4. How It Works
    2.4.1. A Three-second Tour
    On the Producer Side
    On the Consumer Side
    2.4.2. A Three-minute Tour
    On the Producer Side
    On the Consumer Side
    2.4.3. Defining the Contract
    2.4.4. Client Side
    2.4.5. Server Side
    2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.5.1. Technical note
    2.5.2. Consumer side (Loan Issuance)
    2.5.3. Producer side (Fraud Detection server)
    2.5.4. Consumer Side (Loan Issuance) Final Step
    2.6. Dependencies
    2.7. Additional Links
    2.7.1. Spring Cloud Contract video
    2.7.2. Readings
    2.8. 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.5.5. How can I define messaging contracts per topic not per producer?
    For Maven Project
    For Gradle Project
    3.6. Do I need a Binary Storage? Can’t I use Git?
    3.6.1. Protocol convention
    3.6.2. Producer
    3.6.3. Consumer
    3.7. Can I use the Pact Broker?
    3.7.1. Pact Consumer
    3.7.2. Producer
    3.7.3. Pact Consumer (Producer Contract approach)
    3.8. How can I debug the request/response being sent by the generated tests client?
    3.8.1. How can I debug the mapping/request/response being sent by WireMock?
    3.8.2. How can I see what got registered in the HTTP server stub?
    3.8.3. 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. Pushing stubs to SCM
    4.1.14. 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. Pushing stubs to SCM
    4.2.12. 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
    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
    Stub Runner Server Fat Jar
    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. Working with Web Flux
    8.10. Messaging Top-Level Elements
    8.10.1. Output Triggered by a Method
    8.10.2. Output Triggered by a Message
    8.10.3. Consumer/Producer
    8.10.4. Common
    8.11. Multiple Contracts in One File
    8.12. Generating Spring REST Docs snippets from the contracts
    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
    10.6. Using the SCM Stub Downloader
    10.7. Using the Pact 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. History
    2.2. Why a Contract Verifier?
    2.2.1. Testing issues
    2.3. Purposes
    2.4. How It Works
    2.4.1. A Three-second Tour
    On the Producer Side
    On the Consumer Side
    2.4.2. A Three-minute Tour
    On the Producer Side
    On the Consumer Side
    2.4.3. Defining the Contract
    2.4.4. Client Side
    2.4.5. Server Side
    2.5. Step-by-step Guide to Consumer Driven Contracts (CDC)
    2.5.1. Technical note
    2.5.2. Consumer side (Loan Issuance)
    2.5.3. Producer side (Fraud Detection server)
    2.5.4. Consumer Side (Loan Issuance) Final Step
    2.6. Dependencies
    2.7. Additional Links
    2.7.1. Spring Cloud Contract video
    2.7.2. Readings
    2.8. 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.5.5. How can I define messaging contracts per topic not per producer?
    For Maven Project
    For Gradle Project
    3.6. Do I need a Binary Storage? Can’t I use Git?
    3.6.1. Protocol convention
    3.6.2. Producer
    3.6.3. Consumer
    3.7. Can I use the Pact Broker?
    3.7.1. Pact Consumer
    3.7.2. Producer
    3.7.3. Pact Consumer (Producer Contract approach)
    3.8. How can I debug the request/response being sent by the generated tests client?
    3.8.1. How can I debug the mapping/request/response being sent by WireMock?
    3.8.2. How can I see what got registered in the HTTP server stub?
    3.8.3. 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. Pushing stubs to SCM
    4.1.14. 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. Pushing stubs to SCM
    4.2.12. Maven Plugin and STS
    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
    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
    Stub Runner Server Fat Jar
    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. Working with Web Flux
    8.10. Messaging Top-Level Elements
    8.10.1. Output Triggered by a Method
    8.10.2. Output Triggered by a Message
    8.10.3. Consumer/Producer
    8.10.4. Common
    8.11. Multiple Contracts in One File
    8.12. Generating Spring REST Docs snippets from the contracts
    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
    10.6. Using the SCM Stub Downloader
    10.7. Using the Pact 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.1.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),
@@ -1380,7 +1380,7 @@ matching response definition was picked.
    To turn off this feature just bum
 to dump all mappings per artifact id. Also the port at which the given stub server was
 started will be attached.
    3.8.3 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
@@ -1520,8 +1520,7 @@ containing the contracts:
    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 {
@@ -1761,8 +1760,7 @@ extends com.example.base.BaseClass. This setting ta
 packageWithBaseClasses and baseClassForTests.
  • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
 components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders.
    • 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.
    • 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
    • deleteStubsAfterTest: If set to false will not remove any downloaded
+Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsMode: Picks the mode in which stubs will be found and registered
    • deleteStubsAfterTest: If set to false will not remove any downloaded
 contracts from temporary directories
    • 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
@@ -1974,15 +1972,7 @@ 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 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 contractsSnapshotCheckSkip property
-to true.
    4.5 Scenarios
    You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to
+exclude the unwanted dependencies.
    4.4 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\
@@ -1991,10 +1981,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/docs/stateful-behaviour/
    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
+http://wiremock.org/docs/stateful-behaviour/
    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
 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.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
+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
 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,
@@ -2021,7 +2011,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.6.2 How it works
    The image searches for contracts under the /contracts folder.
+or Nexus.
    4.5.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
@@ -2036,8 +2026,8 @@ for group id foo.bar and artifact id .m2. Mount your local .m2 as a volume available at the container’s /root/.m2 path.
 You must not set both EXTERNAL_CONTRACTS_WORK_OFFLINE and EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL.
    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.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)
+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)
 $ ./stop_infra.sh
 # Start docker infra (nodejs, artifactory)
 $ ./setup_infra.sh
@@ -3033,12 +3023,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.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”
+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”
 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.6.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.5.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
@@ -5930,7 +5920,7 @@ to clone the repository and use it as a source of contracts
 to generate tests or stubs.
    Either via environment variables, system properties, properties set
 inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
-properties
    Table 10.1. SCM Stub Downloader properties
    Type of a property
    Name of the property
    Description
    * git.branch (plugin prop)
+properties
    Table 10.1. SCM Stub Downloader properties
    Type of a property
    Name of the property
    Description
    * git.branch (plugin prop)
 
    * stubrunner.properties.git.branch (system prop)
 
    * STUBRUNNER_PROPERTIES_GIT_BRANCH (env prop)
    master
    Which branch to checkout
    * git.username (plugin prop)
 
    * stubrunner.properties.git.username (system prop)
@@ -5946,7 +5936,7 @@ to fetch the Pact contract definitions from the Pact Broker.
 Whatever is set after pact:// will be parsed as the Pact Broker URL.
    Either via environment variables, system properties, properties set
 inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
-properties
    Table 10.2. SCM Stub Downloader properties
    Name of a property
    Default
    Description
    * pactbroker.host (plugin prop)
+properties
    Table 10.2. SCM Stub Downloader properties
    
             
-
+
@@ -645,6 +644,8 @@ taken into consideration
    contractsSnapshotCheckSkip:
    
         
+
    Deprecated. - with 2.1.0 this option is redundant
    
+        
 
    If true then will not assert whether a stub / contract
 JAR was downloaded from local or remote location
    
         
diff --git a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html
index 7d7c2b4c7a..cc5e689ce7 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 @@
       
+
@@ -859,6 +858,8 @@ consideration
    contractsSnapshotCheckSkip:
    
         
+
    Deprecated. - with 2.1.0 this option is redundant
    
+        
 
    If true then will not assert whether a stub / contract
 JAR was downloaded from local or remote location
    
         
diff --git a/spring-cloud-contract-maven-plugin/help-mojo.html b/spring-cloud-contract-maven-plugin/help-mojo.html
index 5926b6b222..0a9606e2a4 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 @@
       
    Name of a property
    Default
    Description
    * pactbroker.host (plugin prop)
 
    * stubrunner.properties.pactbroker.host (system prop)
 
    * STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)
    Host from URL passed to repositoryRoot
    What is the URL of Pact Broker
    * pactbroker.port (plugin prop)
 
    * stubrunner.properties.pactbroker.port (system prop)
diff --git a/spring-cloud-contract-maven-plugin/checkstyle.html b/spring-cloud-contract-maven-plugin/checkstyle.html
index 3aa823c482..a8532e2819 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 @@
       
    		-If true then will not assert whether a stub / contract
-JAR was downloaded from local or remote location
    Default value is: false.
    User property is: contractsSnapshotCheckSkip.
    		Deprecated. - with 2.1.0 this option is redundant
    Default value is: false.
    User property is: contractsSnapshotCheckSkip.
    		
           
    
           
 
    
         
 
 
 
   
     
     
     
     
     If true then will not assert whether a stub / contract
-JAR was downloaded from local or remote location
    Default value is: false.
    User property is: contractsSnapshotCheckSkip.
    		Deprecated. - with 2.1.0 this option is redundant
    Default value is: false.
    User property is: contractsSnapshotCheckSkip.