From 0525798e90c208d4ab85de8ea2b0134e22a900d3 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 19 Jul 2018 14:17:46 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_contract_faq.html | 2 +- ..._cloud_contract_verifier_introduction.html | 6 ++-- ...ing_cloud_contract_verifier_messaging.html | 4 +-- ..._spring_cloud_contract_verifier_setup.html | 10 +++---- ...lti__using_the_pluggable_architecture.html | 4 +-- multi/multi_pr01.html | 2 +- single/spring-cloud-contract.html | 28 +++++++++---------- .../checkstyle.html | 8 +++--- .../complex.html | 8 +++--- .../configs.html | 8 +++--- .../convert-mojo.html | 10 +++---- .../generateStubs-mojo.html | 10 +++---- .../generateTests-mojo.html | 10 +++---- .../help-mojo.html | 10 +++---- spring-cloud-contract-maven-plugin/index.html | 8 +++--- .../integration.html | 8 +++--- .../issue-tracking.html | 8 +++--- spring-cloud-contract-maven-plugin/junit.html | 8 +++--- .../license.html | 8 +++--- .../plugin-info.html | 12 ++++---- .../plugin-management.html | 8 +++--- .../plugins.html | 8 +++--- .../project-info.html | 8 +++--- .../project-reports.html | 8 +++--- .../project-summary.html | 10 +++---- .../pushStubsToScm-mojo.html | 10 +++---- .../run-mojo.html | 10 +++---- .../sitemap.html | 8 +++--- .../source-repository.html | 8 +++--- spring-cloud-contract-maven-plugin/spock.html | 8 +++--- .../team-list.html | 8 +++--- spring-cloud-contract-maven-plugin/usage.html | 8 +++--- spring-cloud-contract.html | 2 +- spring-cloud-contract.xml | 26 ++++++++--------- 34 files changed, 151 insertions(+), 151 deletions(-) diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index 4479298c25..d0f2614d70 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -122,7 +122,7 @@ one to one to the contents of the repo.

Example of a <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>2.0.1.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version> <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> diff --git a/multi/multi__spring_cloud_contract_verifier_introduction.html b/multi/multi__spring_cloud_contract_verifier_introduction.html index 1e3d3e4900..b65c5fea4f 100644 --- a/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -7,7 +7,7 @@ definitions are used to produce the following resources:

client tests). Test code must still be written by hand, and test data is produced by Spring Cloud Contract Verifier.
  • Messaging routes, if you’re using a messaging service. We integrate with Spring Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your -own integrations.
  • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation +own integrations.
  • Acceptance tests (in JUnit 4, JUnit 5 or Spock) are used to verify if server-side implementation of the API is compliant with the contract (server tests). A full test is generated by Spring Cloud Contract Verifier.

    • 2.1 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.1.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, @@ -173,8 +173,8 @@ compliance with the added contracts. By default, the generated tests are under }

      The preceding example uses Spring’s MockMvc to run the tests. This is the default test mode for HTTP contracts. However, JAX-RX client and explicit HTTP invocations can also be used. (To do so, change the testMode property of the plugin to JAX-RS or EXPLICIT, -respectively.)

      Apart from the default JUnit, you can instead use Spock tests, by setting the plugin -testFramework property to Spock.

      [Tip]Tip

      You can now also generate WireMock scenarios based on the contracts, by including an +respectively.)

      Apart from the default JUnit 4, you can instead use JUnit 5 or Spock tests, by setting the plugin +testFramework property to either JUNIT5 or Spock.

      [Tip]Tip

      You can now also generate WireMock scenarios based on the contracts, by including an order number followed by an underscore at the beginning of the contract file names.

      The following example shows an auto-generated test in Spock for a messaging stub contract:

      [source,groovy,indent=0]
      given:
 	 ContractVerifierMessage inputMessage = contractVerifierMessaging.create(
 		\'\'\'{"bookName":"foo"}\'\'\',
diff --git a/multi/multi__spring_cloud_contract_verifier_messaging.html b/multi/multi__spring_cloud_contract_verifier_messaging.html
index e7c6c48768..e94600a920 100644
--- a/multi/multi__spring_cloud_contract_verifier_messaging.html
+++ b/multi/multi__spring_cloud_contract_verifier_messaging.html
@@ -29,8 +29,8 @@ Here’s an example:
      [Note]Note
      If your tests require stubs as well, then @AutoConfigureStubRunner includes the
 messaging configuration, so you only need the one annotation.
      5.3 Publisher-Side Test Generation
      Having the input or outputMessage sections in your DSL results in creation of tests
-on the publisher’s side. By default, JUnit tests are created. However, there is also a
-possibility to create Spock tests.
      There are 3 main scenarios that we should take into consideration:
      • Scenario 1: There is no input message that produces an output message. The output
+on the publisher’s side. By default, JUnit 4 tests are created. However, there is also a
+possibility to create JUnit 5 or Spock tests.
        There are 3 main scenarios that we should take into consideration:
        • Scenario 1: There is no input message that produces an output message. The output
 message  is triggered by a component inside the application (for example, scheduler).
        • Scenario 2: The input message triggers an output message.
        • Scenario 3: The input message is consumed and there is no output message.
        [Important]Important
        The destination passed to messageFrom or sentTo can have different
 meanings for different messaging implementations. For Stream and Integration it is
 first resolved as a destination of a channel. Then, if there is no such destination
diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html
index 511a84e193..50464a6768 100644
--- a/multi/multi__spring_cloud_contract_verifier_setup.html
+++ b/multi/multi__spring_cloud_contract_verifier_setup.html
@@ -132,8 +132,8 @@ should be skipped. By default, it is an empty array.
      • $rootDir/src/test/resources/contracts.
      • generatedTestSourcesDir: Specifies the test source directory where tests generated
 from the Groovy DSL should be placed. By default its value is
 $buildDir/generated-test-sources/contractVerifier.
      • stubsOutputDir: Specifies the directory where the generated WireMock stubs from
-the Groovy DSL should be placed.
      • targetFramework: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework.
      • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
+the Groovy DSL should be placed.
      • targetFramework: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (TestFramework.JUNIT and
+JUnit 5 are supported with JUnit 4 being the default framework.
      • 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.
        • The following properties are used when you want to specify the location of the JAR
 containing the contracts:
 * contractDependency: Specifies the Dependency that provides
@@ -369,8 +369,8 @@ If neither of these values are set, then the value is set to
 org.springframework.cloud.contract.verifier.tests.
      • ruleClassForTests: Specifies a rule that should be added to the generated test
 classes.
      • baseClassForTests: Creates a base class for all generated tests. By default, if you
 use Spock classes, the class is spock.lang.Specification.
      • contractsDirectory: Specifies a directory containing contracts written with the
-GroovyDSL. The default directory is /src/test/resources/contracts.
      • testFramework: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework
      • packageWithBaseClasses: Defines a package where all the base classes reside. This
+GroovyDSL. The default directory is /src/test/resources/contracts.
      • testFramework: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (TestFramework.JUNIT and
+6JUnit 5 are supported with JUnit 4 being the default framework.
      • packageWithBaseClasses: Defines a package where all the base classes reside. This
 setting takes precedence over baseClassForTests. The convention is such that, if you
 have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set
 the value of the packageWithBaseClasses property to com.example.base, then Spring
@@ -606,7 +606,7 @@ 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
+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
 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
diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html
index a22c482ac3..8b13b63426 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_pr01.html b/multi/multi_pr01.html
index f58f0ab5dc..50a4aac2e2 100644
--- a/multi/multi_pr01.html
+++ b/multi/multi_pr01.html
@@ -1,4 +1,4 @@
 
       
    
        Prev   Next
        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.1.BUILD-SNAPSHOT
        Prev   Next
        Spring Cloud Contract Home 1. Spring Cloud Contract
        
\ No newline at end of file
+Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant
        2.1.0.BUILD-SNAPSHOT
        Prev   Next
        Spring Cloud Contract Home 1. Spring Cloud Contract
        
\ No newline at end of file
diff --git a/single/spring-cloud-contract.html b/single/spring-cloud-contract.html
index b547320e68..d71465e6f8 100644
--- a/single/spring-cloud-contract.html
+++ b/single/spring-cloud-contract.html
@@ -1,7 +1,7 @@
 
       
    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. A Three-second Tour
        On the Producer Side
        On the Consumer Side
        2.3.2. A Three-minute Tour
        On the Producer Side
        On the Consumer Side
        2.3.3. Defining the Contract
        2.3.4. Client Side
        2.3.5. 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.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
        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
        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.0.1.BUILD-SNAPSHOT
        1. Spring Cloud Contract
        You need confidence when pushing new features to a new application or service in a
+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),
 covering a range of options for writing tests,  publishing them as assets, and asserting
@@ -12,7 +12,7 @@ definitions are used to produce the following resources:
        client tests). Test code must still be written by hand, and test data is
 produced by Spring Cloud Contract Verifier.
      • Messaging routes, if you’re using a messaging service. We integrate with Spring
 Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your
-own integrations.
      • Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation
+own integrations.
      • Acceptance tests (in JUnit 4, JUnit 5 or Spock) are used to verify if server-side implementation
 of the API is compliant with the contract (server tests). A full test is generated by
 Spring Cloud Contract Verifier.
        • 2.1 Why a Contract Verifier?
        Assume that we have a system consisting of multiple microservices:
        Microservices Architecture
        2.1.1 Testing issues
        If we wanted to test the application in top left corner to determine whether it can
 communicate with other services, we could do one of two things:
        • Deploy all microservices and perform end-to-end tests.
        • Mock other microservices in unit/integration tests.
        Both have their advantages but also a lot of disadvantages.
        Deploy all microservices and perform end to end tests
        Advantages:
        • Simulates production.
        • Tests real communication between services.
        Disadvantages:
        • To test one microservice, we have to deploy 6 microservices, a couple of databases,
@@ -178,8 +178,8 @@ compliance with the added contracts. By default, the generated tests are under
 }
          The preceding example uses Spring’s MockMvc to run the tests. This is the default test
 mode for HTTP contracts. However, JAX-RX client and explicit HTTP invocations can also be
 used. (To do so, change the testMode property of the plugin to JAX-RS or EXPLICIT,
-respectively.)
          Apart from the default JUnit, you can instead use Spock tests, by setting the plugin
-testFramework property to Spock.
          [Tip]Tip
          You can now also generate WireMock scenarios based on the contracts, by including an
+respectively.)
          Apart from the default JUnit 4, you can instead use JUnit 5 or Spock tests, by setting the plugin
+testFramework property to either JUNIT5 or Spock.
          [Tip]Tip
          You can now also generate WireMock scenarios based on the contracts, by including an
 order number followed by an underscore at the beginning of the contract file names.
          The following example shows an auto-generated test in Spock for a messaging stub contract:
          [source,groovy,indent=0]
          given:
 	 ContractVerifierMessage inputMessage = contractVerifierMessaging.create(
 		\'\'\'{"bookName":"foo"}\'\'\',
@@ -902,7 +902,7 @@ one to one to the contents of the repo.
          Example of a <properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>2.0.1.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-contract.version>2.1.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
 		<spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
@@ -1553,8 +1553,8 @@ should be skipped. By default, it is an empty array.
        • $rootDir/src/test/resources/contracts.
        • generatedTestSourcesDir: Specifies the test source directory where tests generated
 from the Groovy DSL should be placed. By default its value is
 $buildDir/generated-test-sources/contractVerifier.
        • stubsOutputDir: Specifies the directory where the generated WireMock stubs from
-the Groovy DSL should be placed.
        • targetFramework: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework.
        • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
+the Groovy DSL should be placed.
        • targetFramework: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (TestFramework.JUNIT and
+JUnit 5 are supported with JUnit 4 being the default framework.
        • 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.
          • The following properties are used when you want to specify the location of the JAR
 containing the contracts:
 * contractDependency: Specifies the Dependency that provides
@@ -1790,8 +1790,8 @@ If neither of these values are set, then the value is set to
 org.springframework.cloud.contract.verifier.tests.
        • ruleClassForTests: Specifies a rule that should be added to the generated test
 classes.
        • baseClassForTests: Creates a base class for all generated tests. By default, if you
 use Spock classes, the class is spock.lang.Specification.
        • contractsDirectory: Specifies a directory containing contracts written with the
-GroovyDSL. The default directory is /src/test/resources/contracts.
        • testFramework: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework
        • packageWithBaseClasses: Defines a package where all the base classes reside. This
+GroovyDSL. The default directory is /src/test/resources/contracts.
        • testFramework: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (TestFramework.JUNIT and
+6JUnit 5 are supported with JUnit 4 being the default framework.
        • packageWithBaseClasses: Defines a package where all the base classes reside. This
 setting takes precedence over baseClassForTests. The convention is such that, if you
 have a contract under (for example) src/test/resources/contract/foo/bar/baz/ and set
 the value of the packageWithBaseClasses property to com.example.base, then Spring
@@ -2027,7 +2027,7 @@ 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
+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
 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
@@ -2144,8 +2144,8 @@ Here’s an example:
          [Note]Note
          If your tests require stubs as well, then @AutoConfigureStubRunner includes the
 messaging configuration, so you only need the one annotation.
          5.3 Publisher-Side Test Generation
          Having the input or outputMessage sections in your DSL results in creation of tests
-on the publisher’s side. By default, JUnit tests are created. However, there is also a
-possibility to create Spock tests.
          There are 3 main scenarios that we should take into consideration:
          • Scenario 1: There is no input message that produces an output message. The output
+on the publisher’s side. By default, JUnit 4 tests are created. However, there is also a
+possibility to create JUnit 5 or Spock tests.
            There are 3 main scenarios that we should take into consideration:
            • Scenario 1: There is no input message that produces an output message. The output
 message  is triggered by a component inside the application (for example, scheduler).
            • Scenario 2: The input message triggers an output message.
            • Scenario 3: The input message is consumed and there is no output message.
            [Important]Important
            The destination passed to messageFrom or sentTo can have different
 meanings for different messaging implementations. For Stream and Integration it is
 first resolved as a destination of a channel. Then, if there is no such destination
@@ -5969,7 +5969,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)
@@ -5985,7 +5985,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
            
         <plugin>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-contract-maven-plugin</artifactId>
-          <version>2.0.1.BUILD-SNAPSHOT</version>
+          <version>2.1.0.BUILD-SNAPSHOT</version>
         </plugin>
         ...
       </plugins>
@@ -340,7 +340,7 @@ origin.
       <plugin>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-contract-maven-plugin</artifactId>
-        <version>2.0.1.BUILD-SNAPSHOT</version>
+        <version>2.1.0.BUILD-SNAPSHOT</version>
       </plugin>
       ...
     </plugins>
diff --git a/spring-cloud-contract-maven-plugin/plugin-management.html b/spring-cloud-contract-maven-plugin/plugin-management.html
index aaaba32f97..77941e358a 100644
--- a/spring-cloud-contract-maven-plugin/plugin-management.html
+++ b/spring-cloud-contract-maven-plugin/plugin-management.html
@@ -1,13 +1,13 @@
 
-    
+    Spring Cloud Contract Maven Plugin – Project Plugin Management
@@ -146,10 +146,10 @@
       
-
+
diff --git a/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html b/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html
index 7087597237..e92c8ef378 100644
--- a/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html
+++ b/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html
@@ -1,13 +1,13 @@
 
-    
+    Spring Cloud Contract Maven Plugin – spring-cloud-contract:pushStubsToScm
@@ -146,10 +146,10 @@
       
            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 1941e4d2c3..85448f71cc 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,10 +146,10 @@
       
            
 
 
   
     
     
     
     
     
            spring-cloud-contract-maven-plugin
            
 
            
 Version2.0.1.BUILD-SNAPSHOT
            2.1.0.BUILD-SNAPSHOT
            
 
            
 Type
 maven-plugin