From a5cfaf8fe321390473a57a0f92f9ea584e5ebd65 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Wed, 3 Jan 2018 10:03:21 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_contract_faq.html | 1 + ...ti__spring_cloud_contract_stub_runner.html | 28 +++--- ..._cloud_contract_verifier_introduction.html | 10 ++- ...multi__spring_cloud_contract_wiremock.html | 15 +++- multi/multi__stub_runner_for_messaging.html | 3 +- ...lti__using_the_pluggable_architecture.html | 9 +- multi/multi_spring-cloud-contract.html | 2 +- single/spring-cloud-contract.html | 68 ++++++++------ .../checkstyle.html | 8 +- .../checkstyle.rss | 6 +- .../complex.html | 8 +- .../configs.html | 9 +- .../convert-mojo.html | 68 +++++++------- .../generateStubs-mojo.html | 8 +- .../generateTests-mojo.html | 80 ++++++++--------- .../help-mojo.html | 8 +- 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 | 8 +- .../plugin-management.html | 8 +- .../plugins.html | 8 +- .../project-info.html | 8 +- .../project-reports.html | 8 +- .../project-summary.html | 8 +- .../run-mojo.html | 8 +- .../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.xml | 88 +++++++++++++------ 34 files changed, 305 insertions(+), 250 deletions(-) diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index 1f974d14b3..1aedba9dac 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -280,6 +280,7 @@ of the JAR containing the contracts:

<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
+		<stubsMode>REMOTE</stubsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
diff --git a/multi/multi__spring_cloud_contract_stub_runner.html b/multi/multi__spring_cloud_contract_stub_runner.html
index f7ddef1819..9077f2ba3b 100644
--- a/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/multi/multi__spring_cloud_contract_stub_runner.html
@@ -159,12 +159,10 @@ publishing {
 }

6.3 Stub Runner Core

Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of Consumer Driven Contracts.

Stub Runner allows you to automatically download the stubs of the provided dependencies (or pick those from the classpath), start WireMock servers for them and feed them with proper stub definitions. -For messaging, special stub routes are defined.

6.3.1 Retrieving stubs

You can pick the following options of acquiring stubs

  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

The latter example is described in the Custom Stub Runner section.

Stub downloading

If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set -to true then Stub Runner will connect to the given server and download the required jars. -It will then unpack the JAR to a temporary folder and reference those files in further -contract processing.

Example:

@AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095")

Classpath scanning

If you DON’T provide the stubrunner.repositoryRoot and stubrunner.workOffline flag will -be set to false (that’s the default) then classpath will get scanned. Let’s look at the -following example:

@AutoConfigureStubRunner(ids = {
+For messaging, special stub routes are defined.
6.3.1 Retrieving stubs
You can pick the following options of acquiring stubs
  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization
The latter example is described in the Custom Stub Runner section.
Stub downloading
You can control the stub downloading via the stubsMode switch. It picks value from the
+StubRunnerProperties.StubsMode enum. You can use the following options
  • StubRunnerProperties.StubsMode.CLASSPATH (default value) - will pick stubs from the classpath
  • StubRunnerProperties.StubsMode.LOCAL - will pick stubs from a local storage (e.g. .m2)
  • StubRunnerProperties.StubsMode.REMOTE - will pick stubs from a remote location
Example:
@AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095", stubsMode = StubRunnerProperties.StubsMode.LOCAL)
Classpath scanning
If you set the stubsMode property to StubRunnerProperties.StubsMode.CLASSPATH
+(or set nothing since CLASSPATH is the default value) then classpath will get scanned.
+Let’s look at the following example:
@AutoConfigureStubRunner(ids = {
     "com.example:beer-api-producer:+:stubs:8095",
     "com.example.foo:bar:1.0.0:superstubs:8096"
 })
If you’ve added the dependencies to your classpath
Maven. 
@@ -249,10 +247,10 @@ HTTP stubs without the need to download artifacts.
'false'

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
+                                  repository

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
     "request": {
         "method": "GET",
         "url": "/ping"
@@ -328,6 +326,7 @@ Check their 
 	Map<StubConfiguration, Collection<Contract>> getContracts();
 }

Example of usage in Spock tests:

@ClassRule @Shared StubRunnerRule rule = new StubRunnerRule()
+		.stubsMode(StubRunnerProperties.StubsMode.REMOTE)
 		.repoRoot(StubRunnerRuleSpec.getResource("/m2repo/repository").toURI().toString())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer")
@@ -459,11 +458,13 @@ its methods as presented below:
@AutoConfigureStubRunner.
+    - org.springframework.cloud.contract.verifier.stubs:bootService
+  stubs-mode: remote
Instead of using the properties you can also use the properties inside the @AutoConfigureStubRunner.
 Below you can find an example of achieving the same result by setting values on the annotation.
@AutoConfigureStubRunner(
 		ids = ["org.springframework.cloud.contract.verifier.stubs:loanIssuance",
 		"org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer",
 		"org.springframework.cloud.contract.verifier.stubs:bootService"],
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		repositoryRoot = "classpath:m2repo/repository/")
Stub Runner Spring registers environment variables in the following manner
 for every registered WireMock server. Example for Stub Runner ids
  com.example:foo, com.example:bar.
  • stubrunner.runningstubs.foo.port
  • stubrunner.runningstubs.bar.port
Which you can reference in your code.

6.5 Stub Runner Spring Cloud

Stub Runner can integrate with Spring Cloud.

For real life examples you can check the

6.5.1 Stubbing Service Discovery

The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

  • DiscoveryClient
  • Ribbon ServerList

that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. @@ -498,7 +499,7 @@ project you can start Stub Runner Boot by executing spring or a subdirectory called config or in ~/.spring-cloud. The file could look like this (example for running stubs installed locally)

stubrunner.yml.  

stubrunner:
-  workOffline: true
+  stubsMode: LOCAL
   ids:
     - com.example:beer-api-producer:+:9876

and then just call spring cloud stubrunner from your terminal window to start @@ -658,6 +659,7 @@ Or set the test as follows:

@SpringBootTest(properties = ["spring.application.name=bar-consumer"])
 @AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		stubsPerConsumer = true)
 @DirtiesContext
 class StubRunnerStubsPerConsumerSpec extends Specification {
@@ -668,6 +670,7 @@ Or set the test as follows:
@AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
 		consumerName = "foo-consumer",
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		stubsPerConsumer = true)
 @DirtiesContext
 class StubRunnerStubsPerConsumerWithConsumerNameSpec extends Specification {
@@ -675,8 +678,7 @@ Or set the test as follows:
foo-consumer in its name (i.e. those from the
 src/test/resources/contracts/foo-consumer/some/contracts/…​ folder) will be allowed to be referenced.
You can check out issue 224 for more
 information about the reasons behind this change.

6.8 Common

This section briefly describes common properties, including:

6.8.1 Common Properties for JUnit and Spring

You can set repetitive properties by using system properties or Spring configuration -properties. Here are their names with their default values:

Property nameDefault valueDescription

stubrunner.minPort

10000

Minimum value of a port for a started WireMock with stubs.

stubrunner.maxPort

15000

Maximum value of a port for a started WireMock with stubs.

stubrunner.repositoryRoot

 

Maven repo URL. If blank, then call the local maven repo.

stubrunner.classifier

stubs

Default classifier for the stub artifacts.

stubrunner.workOffline

false

If true, then do not contact any remote repositories to -download stubs.

stubrunner.ids

 

Array of Ivy notation stubs to download.

stubrunner.username

 

Optional username to access the tool that stores the JARs with +properties. Here are their names with their default values:

Property nameDefault valueDescription

stubrunner.minPort

10000

Minimum value of a port for a started WireMock with stubs.

stubrunner.maxPort

15000

Maximum value of a port for a started WireMock with stubs.

stubrunner.repositoryRoot

 

Maven repo URL. If blank, then call the local maven repo.

stubrunner.classifier

stubs

Default classifier for the stub artifacts.

stubrunner.stubsMode

CLASSPATH

The way you want to fetch and register the stubs

stubrunner.ids

 

Array of Ivy notation stubs to download.

stubrunner.username

 

Optional username to access the tool that stores the JARs with stubs.

stubrunner.password

 

Optional password to access the tool that stores the JARs with stubs.

stubrunner.stubsPerConsumer

false

Set to true if you want to use different stubs for each consumer instead of registering all stubs for every consumer.

stubrunner.consumerName

 

If you want to use a stub for each consumer and want to diff --git a/multi/multi__spring_cloud_contract_verifier_introduction.html b/multi/multi__spring_cloud_contract_verifier_introduction.html index 7e65d06d49..1c320583e3 100644 --- a/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -90,7 +90,8 @@ You would like to feed that instance with a proper stub definition.

At som new HttpEntity<>(request, httpHeaders), FraudServiceResponse.class);

Annotate your test class with @AutoConfigureStubRunner. In the annotation provide the group id and artifact id for the Stub Runner to download stubs of your collaborators.

@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
-@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
+@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
+		stubsMode = StubRunnerProperties.StubsMode.LOCAL)
 @DirtiesContext
 public class LoanApplicationServiceTests {

After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured @@ -331,7 +332,8 @@ Application service):

Add the Spring Cloud Co collaborators. (Optional step) Because you’re playing with the collaborators offline, you can also provide the offline work switch.

@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
-@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
+@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
+		stubsMode = StubRunnerProperties.StubsMode.LOCAL)
 @DirtiesContext
 public class LoanApplicationServiceTests {

Now, when you run your tests, you see something like this:

2016-07-19 14:22:25.403  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Desired version is + - will try to resolve the latest version
 2016-07-19 14:22:25.438  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved version is 0.0.1-SNAPSHOT
@@ -438,8 +440,8 @@ git push origin master

Your CI might run something like

2.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

git checkout master
 git merge --no-ff contract-change-pr

Work online.

Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server -side are automatically downloaded from Nexus/Artifactory. You can switch off the value of -the workOffline parameter in your annotation. The following code shows an example of +side are automatically downloaded from Nexus/Artifactory. You can set the value of +stubsMode to REMOTE. The following code shows an example of achieving the same thing by changing the properties.

stubrunner:
   ids: 'com.example:http-server-dsl:+:stubs:8080'
   repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

2.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add diff --git a/multi/multi__spring_cloud_contract_wiremock.html b/multi/multi__spring_cloud_contract_wiremock.html index 66c70d8d8e..4ede2d2731 100644 --- a/multi/multi__spring_cloud_contract_wiremock.html +++ b/multi/multi__spring_cloud_contract_wiremock.html @@ -143,7 +143,15 @@ pattern. The JSON format is the normal WireMock format, which you can read about WireMock website.

Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native -Wiremock dependencies and exclude the Spring Boot container (if there is one).

11.6 Generating Stubs using REST Docs

Spring REST Docs can be used to generate +Wiremock dependencies and exclude the Spring Boot container (if there is one).

11.6 Customization of WireMock configuration

You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type +in order to customize the WireMock configuration (e.g. add custom transformers). +Example:

		@Bean WireMockConfigurationCustomizer optionsCustomizer() {
+			return new WireMockConfigurationCustomizer() {
+				@Override public void customize(WireMockConfiguration options) {
+// perform your customization here
+				}
+			};
+		}

11.7 Generating Stubs using REST Docs

Spring REST Docs can be used to generate documentation (for example in Asciidoctor format) for an HTTP API with Spring MockMvc or Rest Assured. At the same time that you generate documentation for your API, you can also generate WireMock stubs by using Spring Cloud Contract WireMock. To do so, write your @@ -229,7 +237,7 @@ available on the classpath (by stubs as JARs, for example). After that, you can create a stub using WireMock in a number of different ways, including by using @AutoConfigureWireMock(stubs="classpath:resource.json"), as described earlier in this -document.

11.7 Generating Contracts by Using REST Docs

You can also generate Spring Cloud Contract DSL files and documentation with Spring REST +document.

11.8 Generating Contracts by Using REST Docs

You can also generate Spring Cloud Contract DSL files and documentation with Spring REST Docs. If you do so in combination with Spring Cloud WireMock, you get both the contracts and the stubs.

Why would you want to use this feature? Some people in the community asked questions about a situation in which they would like to move to DSL-based contract definition, @@ -240,12 +248,13 @@ is there because it makes sense to generate both the contracts and the stubs.

"{\"foo\": 23 }")) + .content("{\"foo\": 23, \"bar\" : \"baz\" }")) .andExpect(status().isOk()) .andExpect(content().string("bar")) // first WireMock .andDo(WireMockRestDocs.verify() .jsonPath("$[?(@.foo >= 20)]") + .jsonPath("$[?(@.bar in ['baz','bazz','bazzz'])]") .contentType(MediaType.valueOf("application/json")) .stub("shouldGrantABeerIfOldEnough")) // then Contract DSL documentation diff --git a/multi/multi__stub_runner_for_messaging.html b/multi/multi__stub_runner_for_messaging.html index cfa743cbc3..8186a652d9 100644 --- a/multi/multi__stub_runner_for_messaging.html +++ b/multi/multi__stub_runner_for_messaging.html @@ -184,7 +184,7 @@ property.

Assume that you have the following Maven repository with a deplo } }

Now consider the following Spring configuration:

stubrunner.repositoryRoot: classpath:m2repo/repository/
 stubrunner.ids: org.springframework.cloud.contract.verifier.stubs:streamService:0.0.1-SNAPSHOT:stubs
-
+stubrunner.stubs-mode: remote
 spring:
   cloud:
     stream:
@@ -261,6 +261,7 @@ to disable them explicitly by setting the  stubrunner.stre
 }

Now consider the following Spring configuration:

stubrunner:
   repositoryRoot: classpath:m2repo/repository/
   ids: org.springframework.cloud.contract.verifier.stubs.amqp:spring-cloud-contract-amqp-test:0.4.0-SNAPSHOT:stubs
+  stubs-mode: remote
   amqp:
     enabled: true
 server:
diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html
index 6879bb1be8..e3d592ed0b 100644
--- a/multi/multi__using_the_pluggable_architecture.html
+++ b/multi/multi__using_the_pluggable_architecture.html
@@ -464,8 +464,7 @@ implementation is used. If you provide more than one, the first one on the list
 }

Then you can register it in your spring.factories file, as shown in the following example:

# Example of a custom Stub Downloader Provider
 org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder=\
-com.example.CustomStubDownloaderBuilder

Now you can pick a folder with the source of your stubs.

[Important]Important

If you do not provide any implementation, then the default is used. -If you use the repositoryRoot property or the workOffline flag, then an Aether-based -implementation that downloads stubs from a remote repository is used. If you do not -provide these values, the ClasspathStubProvider (which will scan the classpath) is -used. If you provide more than one, then the first one on the list is used.

Prev   Next
9. Customization Home 11. Spring Cloud Contract WireMock
\ No newline at end of file +com.example.CustomStubDownloaderBuilder

Now you can pick a folder with the source of your stubs.

[Important]Important

If you do not provide any implementation, then the default is used (scan classpath). +If you provide the stubsMode = StubRunnerProperties.StubsMode.LOCAL or +, stubsMode = StubRunnerProperties.StubsMode.REMOTE then the Aether implementation will be used +If you provide more than one, then the first one on the list is used.

Prev   Next
9. Customization Home 11. Spring Cloud Contract WireMock
\ No newline at end of file diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html index fadbbf1b9c..1198d9ea04 100644 --- a/multi/multi_spring-cloud-contract.html +++ b/multi/multi_spring-cloud-contract.html @@ -1,3 +1,3 @@ - Spring Cloud Contract
Spring Cloud Contract
   Next

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. What is this value(consumer(), producer()) ?
3.3. How to do Stubs versioning?
3.3.1. API Versioning
3.3.2. JAR versioning
3.3.3. Dev or prod stubs
3.4. Common repo with contracts
3.4.1. Repo structure
3.4.2. Workflow
3.4.3. Consumer
3.4.4. Producer
3.5. Can I have multiple base classes for tests?
3.6. How can I debug the request/response being sent by the generated tests client?
3.6.1. How can I debug the mapping/request/response being sent by WireMock?
3.6.2. How can I see what got registered in the HTTP server stub?
3.6.3. Can I reference the request from the response?
3.6.4. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Maven Plugin and STS
4.2.12. Spring Cloud Contract Verifier on the Consumer Side
4.3. Stubs and Transitive Dependencies
4.4. Scenarios
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Generating Stubs using REST Docs
11.7. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links
   Next
   
\ No newline at end of file + Spring Cloud Contract
Spring Cloud Contract
   Next

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. What is this value(consumer(), producer()) ?
3.3. How to do Stubs versioning?
3.3.1. API Versioning
3.3.2. JAR versioning
3.3.3. Dev or prod stubs
3.4. Common repo with contracts
3.4.1. Repo structure
3.4.2. Workflow
3.4.3. Consumer
3.4.4. Producer
3.5. Can I have multiple base classes for tests?
3.6. How can I debug the request/response being sent by the generated tests client?
3.6.1. How can I debug the mapping/request/response being sent by WireMock?
3.6.2. How can I see what got registered in the HTTP server stub?
3.6.3. Can I reference the request from the response?
3.6.4. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Maven Plugin and STS
4.2.12. Spring Cloud Contract Verifier on the Consumer Side
4.3. Stubs and Transitive Dependencies
4.4. Scenarios
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links
   Next
   
\ No newline at end of file diff --git a/single/spring-cloud-contract.html b/single/spring-cloud-contract.html index 1a6ed36583..7ddfbe4cc0 100644 --- a/single/spring-cloud-contract.html +++ b/single/spring-cloud-contract.html @@ -1,6 +1,6 @@ - Spring Cloud Contract

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. What is this value(consumer(), producer()) ?
3.3. How to do Stubs versioning?
3.3.1. API Versioning
3.3.2. JAR versioning
3.3.3. Dev or prod stubs
3.4. Common repo with contracts
3.4.1. Repo structure
3.4.2. Workflow
3.4.3. Consumer
3.4.4. Producer
3.5. Can I have multiple base classes for tests?
3.6. How can I debug the request/response being sent by the generated tests client?
3.6.1. How can I debug the mapping/request/response being sent by WireMock?
3.6.2. How can I see what got registered in the HTTP server stub?
3.6.3. Can I reference the request from the response?
3.6.4. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Maven Plugin and STS
4.2.12. Spring Cloud Contract Verifier on the Consumer Side
4.3. Stubs and Transitive Dependencies
4.4. Scenarios
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Generating Stubs using REST Docs
11.7. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links

_Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, + Spring Cloud Contract

Spring Cloud Contract

Table of Contents

1. Spring Cloud Contract
2. Spring Cloud Contract Verifier Introduction
2.1. Why a Contract Verifier?
2.1.1. Testing issues
2.2. Purposes
2.3. How It Works
2.3.1. Defining the contract
2.3.2. Client Side
2.3.3. Server Side
2.4. Step-by-step Guide to Consumer Driven Contracts (CDC)
2.4.1. Technical note
2.4.2. Consumer side (Loan Issuance)
2.4.3. Producer side (Fraud Detection server)
2.4.4. Consumer Side (Loan Issuance) Final Step
2.5. Dependencies
2.6. Additional Links
2.6.1. Spring Cloud Contract video
2.6.2. Readings
2.7. Samples
3. Spring Cloud Contract FAQ
3.1. Why use Spring Cloud Contract Verifier and not X ?
3.2. What is this value(consumer(), producer()) ?
3.3. How to do Stubs versioning?
3.3.1. API Versioning
3.3.2. JAR versioning
3.3.3. Dev or prod stubs
3.4. Common repo with contracts
3.4.1. Repo structure
3.4.2. Workflow
3.4.3. Consumer
3.4.4. Producer
3.5. Can I have multiple base classes for tests?
3.6. How can I debug the request/response being sent by the generated tests client?
3.6.1. How can I debug the mapping/request/response being sent by WireMock?
3.6.2. How can I see what got registered in the HTTP server stub?
3.6.3. Can I reference the request from the response?
3.6.4. Can I reference text from file?
4. Spring Cloud Contract Verifier Setup
4.1. Gradle Project
4.1.1. Prerequisites
4.1.2. Add Gradle Plugin with Dependencies
4.1.3. Gradle and Rest Assured 2.0
4.1.4. Snapshot Versions for Gradle
4.1.5. Add stubs
4.1.6. Run the Plugin
4.1.7. Default Setup
4.1.8. Configure Plugin
4.1.9. Configuration Options
4.1.10. Single Base Class for All Tests
4.1.11. Different Base Classes for Contracts
4.1.12. Invoking Generated Tests
4.1.13. Spring Cloud Contract Verifier on the Consumer Side
4.2. Maven Project
4.2.1. Add maven plugin
4.2.2. Maven and Rest Assured 2.0
4.2.3. Snapshot versions for Maven
4.2.4. Add stubs
4.2.5. Run plugin
4.2.6. Configure plugin
4.2.7. Configuration Options
4.2.8. Single Base Class for All Tests
4.2.9. Different base classes for contracts
4.2.10. Invoking generated tests
4.2.11. Maven Plugin and STS
4.2.12. Spring Cloud Contract Verifier on the Consumer Side
4.3. Stubs and Transitive Dependencies
4.4. Scenarios
5. Spring Cloud Contract Verifier Messaging
5.1. Integrations
5.2. Manual Integration Testing
5.3. Publisher-Side Test Generation
5.3.1. Scenario 1: No Input Message
5.3.2. Scenario 2: Output Triggered by Input
5.3.3. Scenario 3: No Output Message
5.4. Consumer Stub Generation
6. Spring Cloud Contract Stub Runner
6.1. Snapshot versions
6.2. Publishing Stubs as JARs
6.3. Stub Runner Core
6.3.1. Retrieving stubs
Stub downloading
Classpath scanning
6.3.2. Running stubs
Limitations
Running using main app
HTTP Stubs
Viewing registered mappings
Messaging Stubs
6.4. Stub Runner JUnit Rule
6.4.1. Maven settings
6.4.2. Providing fixed ports
6.4.3. Fluent API
6.4.4. Stub Runner with Spring
6.5. Stub Runner Spring Cloud
6.5.1. Stubbing Service Discovery
Test profiles and service discovery
6.5.2. Additional Configuration
6.6. Stub Runner Boot Application
6.6.1. How to use it?
Stub Runner Server
Spring Cloud CLI
6.6.2. Endpoints
HTTP
Messaging
6.6.3. Example
6.6.4. Stub Runner Boot with Service Discovery
6.7. Stubs Per Consumer
6.8. Common
6.8.1. Common Properties for JUnit and Spring
6.8.2. Stub Runner Stubs IDs
7. Stub Runner for Messaging
7.1. Stub triggering
7.1.1. Trigger by Label
7.1.2. Trigger by Group and Artifact Ids
7.1.3. Trigger by Artifact Ids
7.1.4. Trigger All Messages
7.2. Stub Runner Integration
7.2.1. Adding the Runner to the Project
7.2.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.3. Stub Runner Stream
7.3.1. Adding the Runner to the Project
7.3.2. Disabling the functionality
Scenario 1 (no input message)
Scenario 2 (output triggered by input)
Scenario 3 (input with no output)
7.4. Stub Runner Spring AMQP
7.4.1. Adding the Runner to the Project
Triggering the message
Spring AMQP Test Configuration
8. Contract DSL
8.1. Limitations
8.2. Common Top-Level elements
8.2.1. Description
8.2.2. Name
8.2.3. Ignoring Contracts
8.2.4. Passing Values from Files
8.2.5. HTTP Top-Level Elements
8.3. Request
8.4. Response
8.5. Dynamic properties
8.5.1. Dynamic properties inside the body
8.5.2. Regular expressions
8.5.3. Passing Optional Parameters
8.5.4. Executing Custom Methods on the Server Side
8.5.5. Referencing the Request from the Response
8.5.6. Registering Your Own WireMock Extension
8.5.7. Dynamic Properties in the Matchers Sections
8.6. JAX-RS Support
8.7. Async Support
8.8. Working with Context Paths
8.9. Messaging Top-Level Elements
8.9.1. Output Triggered by a Method
8.9.2. Output Triggered by a Message
8.9.3. Consumer/Producer
8.9.4. Common
8.10. Multiple Contracts in One File
9. Customization
9.1. Extending the DSL
9.1.1. Common JAR
9.1.2. Adding the Dependency to the Project
9.1.3. Test the Dependency in the Project’s Dependencies
9.1.4. Test a Dependency in the Plugin’s Dependencies
9.1.5. Referencing classes in DSLs
10. Using the Pluggable Architecture
10.1. Custom Contract Converter
10.1.1. Pact Converter
10.1.2. Pact Contract
10.1.3. Pact for Producers
10.1.4. Pact for Consumers
10.2. Using the Custom Test Generator
10.3. Using the Custom Stub Generator
10.4. Using the Custom Stub Runner
10.5. Using the Custom Stub Downloader
11. Spring Cloud Contract WireMock
11.1. Registering Stubs Automatically
11.2. Using Files to Specify the Stub Bodies
11.3. Alternative: Using JUnit Rules
11.4. Relaxed SSL Validation for Rest Template
11.5. WireMock and Spring MVC Mocks
11.6. Customization of WireMock configuration
11.7. Generating Stubs using REST Docs
11.8. Generating Contracts by Using REST Docs
12. Migrations
12.1. 1.0.x → 1.1.x
12.1.1. New structure of generated stubs
12.2. 1.1.x → 1.2.x
12.2.1. Custom HttpServerStub
12.2.2. New packages for generated tests
12.2.3. New Methods in TemplateProcessor
12.2.4. RestAssured 3.0
12.3. 1.2.x → 2.0.x
12.3.1. No Camel support
13. Links

_Documentation Authors: Adam Dudczak, Mathias Düsterhöft, Marcin Grzejszczak, Dennis Kieselhorst, Jakub Kubryński, Karol Lassak, Olga Maciaszek-Sharma, Mariusz Smykuła, Dave Syer, Jay Bryant

2.0.0.BUILD-SNAPSHOT

1. Spring Cloud Contract

You need confidence when pushing new features to a new application or service in a distributed system. This project provides support for Consumer Driven Contracts and service schemas in Spring applications (for both HTTP and message-based interactions), @@ -95,7 +95,8 @@ You would like to feed that instance with a proper stub definition.

At som new HttpEntity<>(request, httpHeaders), FraudServiceResponse.class);

Annotate your test class with @AutoConfigureStubRunner. In the annotation provide the group id and artifact id for the Stub Runner to download stubs of your collaborators.

@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
-@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
+@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
+		stubsMode = StubRunnerProperties.StubsMode.LOCAL)
 @DirtiesContext
 public class LoanApplicationServiceTests {

After that, during the tests, Spring Cloud Contract automatically finds the stubs (simulating the real service) in the Maven repository and exposes them on a configured @@ -336,7 +337,8 @@ Application service):

Add the Spring Cloud Co collaborators. (Optional step) Because you’re playing with the collaborators offline, you can also provide the offline work switch.

@RunWith(SpringRunner.class)
 @SpringBootTest(webEnvironment=WebEnvironment.NONE)
-@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"}, workOffline = true)
+@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
+		stubsMode = StubRunnerProperties.StubsMode.LOCAL)
 @DirtiesContext
 public class LoanApplicationServiceTests {

Now, when you run your tests, you see something like this:

2016-07-19 14:22:25.403  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Desired version is + - will try to resolve the latest version
 2016-07-19 14:22:25.438  INFO 41050 --- [           main] o.s.c.c.stubrunner.AetherStubDownloader  : Resolved version is 0.0.1-SNAPSHOT
@@ -443,8 +445,8 @@ git push origin master

Your CI might run something like

2.4.4 Consumer Side (Loan Issuance) Final Step

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server):

Merge branch to master.

git checkout master
 git merge --no-ff contract-change-pr

Work online.

Now you can disable the offline work for Spring Cloud Contract Stub Runner and indicate where the repository with your stubs is located. At this moment the stubs of the server -side are automatically downloaded from Nexus/Artifactory. You can switch off the value of -the workOffline parameter in your annotation. The following code shows an example of +side are automatically downloaded from Nexus/Artifactory. You can set the value of +stubsMode to REMOTE. The following code shows an example of achieving the same thing by changing the properties.

stubrunner:
   ids: 'com.example:http-server-dsl:+:stubs:8080'
   repositoryRoot: http://repo.spring.io/libs-snapshot

That’s it!

2.5 Dependencies

The best way to add dependencies is to use the proper starter dependency.

For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add @@ -731,6 +733,7 @@ of the JAR containing the contracts:

<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
+		<stubsMode>REMOTE</stubsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
@@ -1685,12 +1688,10 @@ publishing {
 }

6.3 Stub Runner Core

Runs stubs for service collaborators. Treating stubs as contracts of services allows to use stub-runner as an implementation of Consumer Driven Contracts.

Stub Runner allows you to automatically download the stubs of the provided dependencies (or pick those from the classpath), start WireMock servers for them and feed them with proper stub definitions. -For messaging, special stub routes are defined.

6.3.1 Retrieving stubs

You can pick the following options of acquiring stubs

  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization

The latter example is described in the Custom Stub Runner section.

Stub downloading

If you provide the stubrunner.repositoryRoot or stubrunner.workOffline flag will be set -to true then Stub Runner will connect to the given server and download the required jars. -It will then unpack the JAR to a temporary folder and reference those files in further -contract processing.

Example:

@AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095")

Classpath scanning

If you DON’T provide the stubrunner.repositoryRoot and stubrunner.workOffline flag will -be set to false (that’s the default) then classpath will get scanned. Let’s look at the -following example:

@AutoConfigureStubRunner(ids = {
+For messaging, special stub routes are defined.
6.3.1 Retrieving stubs
You can pick the following options of acquiring stubs
  • Aether based solution that downloads JARs with stubs from Artifactory / Nexus
  • Classpath scanning solution that searches classpath via pattern to retrieve stubs
  • Write your own implementation of the org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder for full customization
The latter example is described in the Custom Stub Runner section.
Stub downloading
You can control the stub downloading via the stubsMode switch. It picks value from the
+StubRunnerProperties.StubsMode enum. You can use the following options
  • StubRunnerProperties.StubsMode.CLASSPATH (default value) - will pick stubs from the classpath
  • StubRunnerProperties.StubsMode.LOCAL - will pick stubs from a local storage (e.g. .m2)
  • StubRunnerProperties.StubsMode.REMOTE - will pick stubs from a remote location
Example:
@AutoConfigureStubRunner(repositoryRoot="http://foo.bar", ids = "com.example:beer-api-producer:+:stubs:8095", stubsMode = StubRunnerProperties.StubsMode.LOCAL)
Classpath scanning
If you set the stubsMode property to StubRunnerProperties.StubsMode.CLASSPATH
+(or set nothing since CLASSPATH is the default value) then classpath will get scanned.
+Let’s look at the following example:
@AutoConfigureStubRunner(ids = {
     "com.example:beer-api-producer:+:stubs:8095",
     "com.example.foo:bar:1.0.0:superstubs:8096"
 })
If you’ve added the dependencies to your classpath
Maven. 
@@ -1775,10 +1776,10 @@ HTTP stubs without the need to download artifacts.
'false'

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
+                                  repository

HTTP Stubs

Stubs are defined in JSON documents, whose syntax is defined in WireMock documentation

Example:

{
     "request": {
         "method": "GET",
         "url": "/ping"
@@ -1854,6 +1855,7 @@ Check their 
 	Map<StubConfiguration, Collection<Contract>> getContracts();
 }

Example of usage in Spock tests:

@ClassRule @Shared StubRunnerRule rule = new StubRunnerRule()
+		.stubsMode(StubRunnerProperties.StubsMode.REMOTE)
 		.repoRoot(StubRunnerRuleSpec.getResource("/m2repo/repository").toURI().toString())
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs", "loanIssuance")
 		.downloadStub("org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer")
@@ -1985,11 +1987,13 @@ its methods as presented below:
@AutoConfigureStubRunner.
+    - org.springframework.cloud.contract.verifier.stubs:bootService
+  stubs-mode: remote
Instead of using the properties you can also use the properties inside the @AutoConfigureStubRunner.
 Below you can find an example of achieving the same result by setting values on the annotation.
@AutoConfigureStubRunner(
 		ids = ["org.springframework.cloud.contract.verifier.stubs:loanIssuance",
 		"org.springframework.cloud.contract.verifier.stubs:fraudDetectionServer",
 		"org.springframework.cloud.contract.verifier.stubs:bootService"],
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		repositoryRoot = "classpath:m2repo/repository/")
Stub Runner Spring registers environment variables in the following manner
 for every registered WireMock server. Example for Stub Runner ids
  com.example:foo, com.example:bar.
  • stubrunner.runningstubs.foo.port
  • stubrunner.runningstubs.bar.port
Which you can reference in your code.

6.5 Stub Runner Spring Cloud

Stub Runner can integrate with Spring Cloud.

For real life examples you can check the

6.5.1 Stubbing Service Discovery

The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

  • DiscoveryClient
  • Ribbon ServerList

that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. @@ -2024,7 +2028,7 @@ project you can start Stub Runner Boot by executing spring or a subdirectory called config or in ~/.spring-cloud. The file could look like this (example for running stubs installed locally)

stubrunner.yml.  

stubrunner:
-  workOffline: true
+  stubsMode: LOCAL
   ids:
     - com.example:beer-api-producer:+:9876

and then just call spring cloud stubrunner from your terminal window to start @@ -2184,6 +2188,7 @@ Or set the test as follows:

@SpringBootTest(properties = ["spring.application.name=bar-consumer"])
 @AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		stubsPerConsumer = true)
 @DirtiesContext
 class StubRunnerStubsPerConsumerSpec extends Specification {
@@ -2194,6 +2199,7 @@ Or set the test as follows:
@AutoConfigureStubRunner(ids = "org.springframework.cloud.contract.verifier.stubs:producerWithMultipleConsumers",
 		repositoryRoot = "classpath:m2repo/repository/",
 		consumerName = "foo-consumer",
+		stubsMode = StubRunnerProperties.StubsMode.REMOTE,
 		stubsPerConsumer = true)
 @DirtiesContext
 class StubRunnerStubsPerConsumerWithConsumerNameSpec extends Specification {
@@ -2201,8 +2207,7 @@ Or set the test as follows:
foo-consumer in its name (i.e. those from the
 src/test/resources/contracts/foo-consumer/some/contracts/…​ folder) will be allowed to be referenced.
You can check out issue 224 for more
 information about the reasons behind this change.

6.8 Common

This section briefly describes common properties, including:

6.8.1 Common Properties for JUnit and Spring

You can set repetitive properties by using system properties or Spring configuration -properties. Here are their names with their default values:

- - - - - - - - - - - @@ -473,7 +461,7 @@ local maven repository
Default value is: false.
Use - + @@ -484,7 +472,7 @@ local maven repository
Default value is: false.
Use - + @@ -496,7 +484,7 @@ local maven repository
Default value is: false.
Use @Ignored tests
 - + @@ -507,7 +495,7 @@ local maven repository
Default value is: false.
Use - + @@ -518,7 +506,7 @@ local maven repository
Default value is: false.
Use - + @@ -529,7 +517,7 @@ local maven repository
Default value is: false.
Use - + @@ -548,7 +536,7 @@ test source file that will have the package last folders to and attach Base to its name.
User property is: packageWithBaseClasses.
 - + @@ -559,7 +547,7 @@ last folders to and attach Base to its name.
User property is(no description)
 - + @@ -570,7 +558,7 @@ last folders to and attach Base to its name.
User property is(no description)
Default value is: false.
User property is: spring.cloud.contract.verifier.skip.
 - + @@ -581,7 +569,7 @@ last folders to and attach Base to its name.
User property is(no description)
Default value is: false.
User property is: skipTests.
 - + @@ -592,6 +580,17 @@ last folders to and attach Base to its name.
User property isStatic imports that should be added to generated tests
 + + + + + + + + + + + @@ -784,21 +783,6 @@ taken into consideration
  • User Property: contractsRepositoryUsername
    • -

    contractsWorkOffline:

    - -
    If true then JAR with contracts will be taken from -local maven repository
    - -
      - -
    • Type: boolean
      • - -
    • Required: No
      • - -
    • User Property: contractsWorkOffline
      • - -
    • Default: false
      • -

    excludedFiles:

    Patterns that should not be taken into account for processing
    @@ -934,6 +918,20 @@ last folders to and attach Base to its name.
  • Required: No
    • +

    stubsMode:

    + +
    Picks the mode in which stubs will be found and registered
    + +
      + +
    • Type: org.springframework.cloud.contract.stubrunner.spring.StubRunnerProperties$StubsMode
      • + +
    • Required: No
      • + +
    • User Property: stubsMode
      • + +
    • Default: CLASSPATH
      • +

    testFramework:

    (no description)
    @@ -971,7 +969,7 @@ last folders to and attach Base to its name.
    -

    Copyright © 2016–2017 +

    Copyright © 2016–2018 Spring. All rights reserved.

    diff --git a/spring-cloud-contract-maven-plugin/help-mojo.html b/spring-cloud-contract-maven-plugin/help-mojo.html index dea18b97bd..e48000d5e1 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 @@
    -

    Copyright © 2016–2017 +

    Copyright © 2016–2018 Spring. All rights reserved.

    diff --git a/spring-cloud-contract-maven-plugin/index.html b/spring-cloud-contract-maven-plugin/index.html index 5a67c5dbe2..4a6430a21c 100644 --- a/spring-cloud-contract-maven-plugin/index.html +++ b/spring-cloud-contract-maven-plugin/index.html @@ -1,13 +1,13 @@ - + Spring Cloud Contract Maven Plugin – @@ -146,7 +146,7 @@
    Property nameDefault valueDescription

    stubrunner.minPort

    10000

    Minimum value of a port for a started WireMock with stubs.

    stubrunner.maxPort

    15000

    Maximum value of a port for a started WireMock with stubs.

    stubrunner.repositoryRoot

    		 

    Maven repo URL. If blank, then call the local maven repo.

    stubrunner.classifier

    stubs

    Default classifier for the stub artifacts.

    stubrunner.workOffline

    false

    If true, then do not contact any remote repositories to -download stubs.

    stubrunner.ids

    		 

    Array of Ivy notation stubs to download.

    stubrunner.username

    		 

    Optional username to access the tool that stores the JARs with +properties. Here are their names with their default values:

    - - - - - - - - - - - @@ -417,7 +405,7 @@ local maven repository
    Default value is: false.
    Use - + @@ -430,7 +418,7 @@ local maven repository
    Default value is: false.
    Use further processing.
    Default value is: false.
    User property is: excludeBuildFolders.
     - + @@ -441,7 +429,7 @@ further processing.
    Default value is: false.
    User p     - + @@ -455,7 +443,7 @@ further processing.
    Default value is: false.
    User p maven project.


    Default value is: ${basedir}.
    User property is: contractsDirectory.
     - + @@ -467,6 +455,17 @@ maven project.


    Default value is: ${basedir}.
    Us be placed. You can then mention them in your packaging task to create jar with stubs
    Default value is: ${project.build.directory}/stubs/.
     + + + + + + + + + + +
    Property nameDefault valueDescription

    stubrunner.minPort

    10000

    Minimum value of a port for a started WireMock with stubs.

    stubrunner.maxPort

    15000

    Maximum value of a port for a started WireMock with stubs.

    stubrunner.repositoryRoot

    		 

    Maven repo URL. If blank, then call the local maven repo.

    stubrunner.classifier

    stubs

    Default classifier for the stub artifacts.

    stubrunner.stubsMode

    CLASSPATH

    The way you want to fetch and register the stubs

    stubrunner.ids

    		 

    Array of Ivy notation stubs to download.

    stubrunner.username

    		 

    Optional username to access the tool that stores the JARs with stubs.

    stubrunner.password

    		 

    Optional password to access the tool that stores the JARs with stubs.

    stubrunner.stubsPerConsumer

    false

    Set to true if you want to use different stubs for each consumer instead of registering all stubs for every consumer.

    stubrunner.consumerName

    		 

    If you want to use a stub for each consumer and want to @@ -2396,7 +2401,7 @@ property.

    Assume that you have the following Maven repository with a deplo } }

    Now consider the following Spring configuration:

    stubrunner.repositoryRoot: classpath:m2repo/repository/
 stubrunner.ids: org.springframework.cloud.contract.verifier.stubs:streamService:0.0.1-SNAPSHOT:stubs
-
+stubrunner.stubs-mode: remote
 spring:
   cloud:
     stream:
@@ -2473,6 +2478,7 @@ to disable them explicitly by setting the  stubrunner.stre
 }

    Now consider the following Spring configuration:

    stubrunner:
   repositoryRoot: classpath:m2repo/repository/
   ids: org.springframework.cloud.contract.verifier.stubs.amqp:spring-cloud-contract-amqp-test:0.4.0-SNAPSHOT:stubs
+  stubs-mode: remote
   amqp:
     enabled: true
 server:
@@ -4406,11 +4412,10 @@ implementation is used. If you provide more than one, the first one on the list
 }

    Then you can register it in your spring.factories file, as shown in the following example:

    # Example of a custom Stub Downloader Provider
 org.springframework.cloud.contract.stubrunner.StubDownloaderBuilder=\
-com.example.CustomStubDownloaderBuilder

    Now you can pick a folder with the source of your stubs.

    [Important]Important

    If you do not provide any implementation, then the default is used. -If you use the repositoryRoot property or the workOffline flag, then an Aether-based -implementation that downloads stubs from a remote repository is used. If you do not -provide these values, the ClasspathStubProvider (which will scan the classpath) is -used. If you provide more than one, then the first one on the list is used.

    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a +com.example.CustomStubDownloaderBuilder

    Now you can pick a folder with the source of your stubs.

    [Important]Important

    If you do not provide any implementation, then the default is used (scan classpath). +If you provide the stubsMode = StubRunnerProperties.StubsMode.LOCAL or +, stubsMode = StubRunnerProperties.StubsMode.REMOTE then the Aether implementation will be used +If you provide more than one, then the first one on the list is used.

    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is @@ -4553,7 +4558,15 @@ pattern. The JSON format is the normal WireMock format, which you can read about WireMock website.

    Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native -Wiremock dependencies and exclude the Spring Boot container (if there is one).

    11.6 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate +Wiremock dependencies and exclude the Spring Boot container (if there is one).

    11.6 Customization of WireMock configuration

    You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type +in order to customize the WireMock configuration (e.g. add custom transformers). +Example:

    		@Bean WireMockConfigurationCustomizer optionsCustomizer() {
+			return new WireMockConfigurationCustomizer() {
+				@Override public void customize(WireMockConfiguration options) {
+// perform your customization here
+				}
+			};
+		}

    11.7 Generating Stubs using REST Docs

    Spring REST Docs can be used to generate documentation (for example in Asciidoctor format) for an HTTP API with Spring MockMvc or Rest Assured. At the same time that you generate documentation for your API, you can also generate WireMock stubs by using Spring Cloud Contract WireMock. To do so, write your @@ -4639,7 +4652,7 @@ available on the classpath (by stubs as JARs, for example). After that, you can create a stub using WireMock in a number of different ways, including by using @AutoConfigureWireMock(stubs="classpath:resource.json"), as described earlier in this -document.

    11.7 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST +document.

    11.8 Generating Contracts by Using REST Docs

    You can also generate Spring Cloud Contract DSL files and documentation with Spring REST Docs. If you do so in combination with Spring Cloud WireMock, you get both the contracts and the stubs.

    Why would you want to use this feature? Some people in the community asked questions about a situation in which they would like to move to DSL-based contract definition, @@ -4650,12 +4663,13 @@ is there because it makes sense to generate both the contracts and the stubs.

    "{\"foo\": 23 }")) + .content("{\"foo\": 23, \"bar\" : \"baz\" }")) .andExpect(status().isOk()) .andExpect(content().string("bar")) // first WireMock .andDo(WireMockRestDocs.verify() .jsonPath("$[?(@.foo >= 20)]") + .jsonPath("$[?(@.bar in ['baz','bazz','bazzz'])]") .contentType(MediaType.valueOf("application/json")) .stub("shouldGrantABeerIfOldEnough")) // then Contract DSL documentation diff --git a/spring-cloud-contract-maven-plugin/checkstyle.html b/spring-cloud-contract-maven-plugin/checkstyle.html index f6bc5ab4c1..425af2122a 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 @@
    contractsWorkOfflineboolean-If true then JAR with contracts will be taken from -local maven repository
    Default value is: false.
    User property is: contractsWorkOffline.
    destination File(no description)
    Default value is: ${basedir}.
    User property is: stubsDirectory.
    excludeBuildFolders
    skip(no description)
    Default value is: false.
    User property is: spring.cloud.contract.verifier.skip.
    source
    stubsDirectory
    stubsModeStubRunnerProperties$StubsMode-Picks the mode in which stubs will be found and registered
    Default value is: CLASSPATH.
    User property is: stubsMode.
    @@ -581,21 +580,6 @@ taken into consideration
  • User Property: contractsRepositoryUsername
    • -

    contractsWorkOffline:

    - -
    If true then JAR with contracts will be taken from -local maven repository
    - -
      - -
    • Type: boolean
      • - -
    • Required: No
      • - -
    • User Property: contractsWorkOffline
      • - -
    • Default: false
      • -

    destination:

    (no description)
    @@ -670,6 +654,20 @@ create jar with stubs
  • Required: No
  • Default: ${project.build.directory}/stubs/
    • +
    +

    stubsMode:

    + +
    Picks the mode in which stubs will be found and registered
    + +
      + +
    • Type: org.springframework.cloud.contract.stubrunner.spring.StubRunnerProperties$StubsMode
      • + +
    • Required: No
      • + +
    • User Property: stubsMode
      • + +
    • Default: CLASSPATH
    @@ -684,7 +682,7 @@ create jar with stubs
    -

    Copyright © 2016–2017 +

    Copyright © 2016–2018 Spring. All rights reserved.

    diff --git a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html index c673fb09b7..81429baec8 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 @@
    -

    Copyright © 2016–2017 +

    Copyright © 2016–2018 Spring. All rights reserved.

    diff --git a/spring-cloud-contract-maven-plugin/generateTests-mojo.html b/spring-cloud-contract-maven-plugin/generateTests-mojo.html index 184b866f6a..57781fc3e4 100644 --- a/spring-cloud-contract-maven-plugin/generateTests-mojo.html +++ b/spring-cloud-contract-maven-plugin/generateTests-mojo.html @@ -1,13 +1,13 @@ - + Spring Cloud Contract Maven Plugin – spring-cloud-contract:generateTests @@ -146,7 +146,7 @@
    contractsWorkOfflineboolean-If true then JAR with contracts will be taken from -local maven repository
    Default value is: false.
    User property is: contractsWorkOffline.
    excludedFiles ListPatterns that should not be taken into account for processing
    generatedTestSourcesDir(no description)
    Default value is: ${project.build.directory}/generated-test-sources/contracts.
    ignoredFiles
    importsImports that should be added to generated tests
    mavenTestSkip(no description)
    Default value is: false.
    User property is: maven.test.skip.
    nameSuffixForTests(no description)
    packageWithBaseClasses
    ruleClassForTests
    skip
    skipTests
    staticImports
    stubsModeStubRunnerProperties$StubsMode-Picks the mode in which stubs will be found and registered
    Default value is: CLASSPATH.
    User property is: stubsMode.
    testFramework