From c2e704b90935d4181a51b3d7576d661792cd3122 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Sat, 31 Mar 2018 16:23:56 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__migrations.html | 3 +- multi/multi__spring_cloud_contract_faq.html | 137 ++++- ..._cloud_contract_verifier_introduction.html | 8 +- ..._spring_cloud_contract_verifier_setup.html | 60 +- ...lti__using_the_pluggable_architecture.html | 18 +- multi/multi_pr01.html | 4 +- multi/multi_spring-cloud-contract.html | 2 +- single/spring-cloud-contract.html | 230 +++++++- .../checkstyle.html | 2 +- .../checkstyle.rss | 20 +- .../convert-mojo.html | 47 +- .../generateStubs-mojo.html | 31 +- .../generateTests-mojo.html | 79 ++- .../plugin-info.html | 4 + .../pushStubsToScm-mojo.html | 551 ++++++++++++++++++ spring-cloud-contract.xml | 383 +++++++++++- 16 files changed, 1426 insertions(+), 153 deletions(-) create mode 100644 spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html diff --git a/multi/multi__migrations.html b/multi/multi__migrations.html index 6c7c589f4c..9d777b3c08 100644 --- a/multi/multi__migrations.html +++ b/multi/multi__migrations.html @@ -1,6 +1,7 @@ - 12. Migrations
12. Migrations
Prev   Next

12. Migrations

This section covers migrating from one version of Spring Cloud Contract Verifier to the + 12. Migrations

12. Migrations
Prev   Next

12. Migrations

[Tip]Tip

For up to date migration guides please visit +the project’s wiki page.

This section covers migrating from one version of Spring Cloud Contract Verifier to the next version. It covers the following versions upgrade paths:

12.1 1.0.x → 1.1.x

This section covers upgrading from version 1.0 to version 1.1.

12.1.1 New structure of generated stubs

In 1.1.x we have introduced a change to the structure of generated stubs. If you have been using the @AutoConfigureWireMock notation to use the stubs from the classpath, it no longer works. The following example shows how the @AutoConfigureWireMock notation diff --git a/multi/multi__spring_cloud_contract_faq.html b/multi/multi__spring_cloud_contract_faq.html index 4ef3035b6b..d7e6aff236 100644 --- a/multi/multi__spring_cloud_contract_faq.html +++ b/multi/multi__spring_cloud_contract_faq.html @@ -1,8 +1,8 @@ - 3. Spring Cloud Contract FAQ

3. Spring Cloud Contract FAQ
Prev   Next

3. Spring Cloud Contract FAQ

3.1 Why use Spring Cloud Contract Verifier and not X ?

For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating + 3. Spring Cloud Contract FAQ

3. Spring Cloud Contract FAQ
Prev   Next

3. Spring Cloud Contract FAQ

3.1 Why use Spring Cloud Contract Verifier and not X ?

For the time being Spring Cloud Contract is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make -Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

  • Possibility to do CDC with messaging
  • Clear and easy to use, statically typed DSL
  • Possibility to copy paste your current JSON file to the contract and only edit its elements
  • Automatic generation of tests from the defined Contract
  • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
  • Spring Cloud integration - no discovery service is needed for integration tests

3.2 I don’t want to write a contract in Groovy!

No problem. You can write a contract in YAML!

3.3 What is this value(consumer(), producer()) ?

One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. +Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

  • Possibility to do CDC with messaging
  • Clear and easy to use, statically typed DSL
  • Possibility to copy paste your current JSON file to the contract and only edit its elements
  • Automatic generation of tests from the defined Contract
  • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
  • Spring Cloud integration - no discovery service is needed for integration tests
  • Spring Cloud Contract integrates with Pact out of the box and provides easy hooks to extend its functionality
  • Via Docker adds support for any language & framework used

3.2 I don’t want to write a contract in Groovy!

No problem. You can write a contract in YAML!

3.3 What is this value(consumer(), producer()) ?

One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. What typically makes that difficult are the hard-coded values of request / response elements. For example dates or ids. Imagine the following JSON request

{
     "time" : "2016-10-10 20:10:15",
@@ -82,7 +82,7 @@ It can be related to security issues where the consumers can’t clone the p
 contracts in a single place then you, as a producer, will know how many consumers you have and which
 consumer will you break with your local changes.
3.5.1 Repo structure
Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1,
 client2, client3. Then in the repository with common contracts you would have the following setup
-(which you can checkout here:
├── com
+(which you can checkout here):
├── com
 │   └── example
 │       └── server
 │           ├── client1
@@ -115,15 +115,15 @@ one to one to the contents of the repo.
Example of a <parent>
 		<groupId>org.springframework.boot</groupId>
 		<artifactId>spring-boot-starter-parent</artifactId>
-		<version>1.5.10.RELEASE</version>
+		<version>2.0.0.BUILD-SNAPSHOT</version>
 		<relativePath />
 	</parent>
 
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>1.2.5.BUILD-SNAPSHOT</spring-cloud-contract.version>
-		<spring-cloud-dependencies.version>Edgware.BUILD-SNAPSHOT</spring-cloud-dependencies.version>
+		<spring-cloud-contract.version>2.0.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
 
@@ -280,6 +280,7 @@ of the JAR containing the contracts:
<groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
+		<contractsMode>REMOTE</contractsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
@@ -388,20 +389,126 @@ configurations {
         include: "**/*",
         excludes: [
             "**/${project.name}/**"",
-            **/${first-topic}/**",
-            **/${second-topic}/**])
-}
  • Create task dependencies:
unzipContracts.dependsOn("getContracts")
+            "**/${first-topic}/**",
+            "**/${second-topic}/**"])
+}
  • Create task dependencies:
unzipContracts.dependsOn("getContracts")
 deleteUnwantedContracts.dependsOn("unzipContracts")
-build.dependsOn("deleteUnwantedContracts")
  • Configure plugin by specifying the directory containing contracts using contractsDslDir property
contracts {
-
+build.dependsOn("deleteUnwantedContracts")
  • Configure plugin by specifying the directory containing contracts using contractsDslDir property
contracts {
     contractsDslDir = new File("${buildDir}/unpackedContracts")
-}

3.6 Can I have multiple base classes for tests?

Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins.

3.7 How can I debug the request/response being sent by the generated tests client?

The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

logging.level.org.apache.http.wire=DEBUG

3.7.1 How can I debug the mapping/request/response being sent by WireMock?

Starting from version 1.2.0 we turn on WireMock logging to +}

3.6 Do I need a Binary Storage? Can’t I use Git?

In the polyglot world, there are languages that don’t use binary storages like +Artifactory or Nexus. Starting from Spring Cloud Contract version 2.0.0 we provide +mechanisms to store contracts and stubs in a SCM repository. Currently the +only supported SCM is Git.

The repository would have to the following setup +(which you can checkout here):

.
+└── META-INF
+    └── com.example
+        └── beer-api-producer-git
+            └── 0.0.1-SNAPSHOT
+                ├── contracts
+                │   └── beer-api-consumer
+                │       ├── messaging
+                │       │   ├── shouldSendAcceptedVerification.groovy
+                │       │   └── shouldSendRejectedVerification.groovy
+                │       └── rest
+                │           ├── shouldGrantABeerIfOldEnough.groovy
+                │           └── shouldRejectABeerIfTooYoung.groovy
+                └── mappings
+                    └── beer-api-consumer
+                        └── rest
+                            ├── shouldGrantABeerIfOldEnough.json
+                            └── shouldRejectABeerIfTooYoung.json

Under META-INF folder:

  • we group applications via groupId (e.g. com.example)
  • then each application is represented via the artifactId (e.g. beer-api-producer-git)
  • next, the version of the application. The version is mandatory! (e.g. 0.0.1-SNAPSHOT)

  • finally, there are two folders:

    • contracts - the good practice is to store the contracts required by each +consumer in the folder with the consumer name (e.g. beer-api-consumer). That way you +can use the stubs-per-consumer feature. Further directory structure is arbitrary.
    • mappings - in this folder the Maven / Gradle Spring Cloud Contract plugins will push +the stub server mappings. On the consumer side, Stub Runner will scan this folder +to start stub servers with stub definitions. The folder structure will be a copy +of the one created in the contracts subfolder.

3.6.1 Protocol convention

In order to control the type and location of the source of contracts (whether it’s +a binary storage or an SCM repository), you can use the protocol in the URL of +the repository. Spring Cloud Contract iterates over registered protocol resolvers +and tries to fetch the contracts (via a plugin) or stubs (via Stub Runner).

For the SCM functionality, currently, we support the Git repository. To use it, +in the property, where the repository URL needs to be placed you just have to prefix +the connection URL with git://. Here you can find a couple of examples:

git://file:///foo/bar
+git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git
+git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git

3.6.2 Producer

For the producer, to use the SCM approach, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the SCM implementation via the URL that contains +the git:// protocol.

[Important]Important

You have to manually add the pushStubsToScm +goal in Maven or execute (bind) the pushStubsToScm task in +Gradle. We don’t push stubs to origin of your git +repository out of the box.

Maven.  +

<plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <version>${project.version}</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <executions>
+        <execution>
+            <phase>package</phase>
+            <goals>
+                <!-- By default we will not push the stubs back to SCM,
+                you have to explicitly add it as a goal -->
+                <goal>pushStubsToScm</goal>
+            </goals>
+        </execution>
+    </executions>
+</plugin>

+

Gradle.  +

contracts {
+	// We want to pick contracts from a Git repository
+	contractDependency {
+		stringNotation = "${project.group}:${project.name}:${project.version}"
+	}
+	/*
+	We reuse the contract dependency section to set up the path
+	to the folder that contains the contract definitions. In our case the
+	path will be /groupId/artifactId/version/contracts
+	 */
+	contractRepository {
+		repositoryUrl = "git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git"
+	}
+	// The mode can't be classpath
+	contractsMode = "REMOTE"
+	// Base class mappings etc.
+}
+
+/*
+In this scenario we want to publish stubs to SCM whenever
+the `publish` task is executed
+*/
+publish.dependsOn("publishStubsToScm")

+

With such a setup:

  • Git project will be cloned to a temporary directory
  • The SCM stub downloader will go to META-INF/groupId/artifactId/version/contracts folder +to find contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/contracts
  • Tests will be generated from the contracts
  • Stubs will be created from the contracts
  • Once the tests pass, the stubs will be committed in the cloned repository
  • Finally, a push will be done to that repo’s origin

3.6.3 Consumer

On the consumer side when passing the repositoryRoot parameter, +either from the @AutoConfigureStubRunner annotation, the +JUnit rule or properties, it’s enough to pass the URL of the +SCM repository, prefixed with the protocol. For example

@AutoConfigureStubRunner(
+    stubsMode="REMOTE",
+    repositoryRoot="git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git",
+    ids="com.example:bookstore:0.0.1.RELEASE"
+)

With such a setup:

  • Git project will be cloned to a temporary directory
  • The SCM stub downloader will go to META-INF/groupId/artifactId/version/ folder +to find stub definitions and contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/
  • Stub servers will be started and fed with mappings
  • Messaging definitions will be read and used in the messaging tests

3.7 How can I debug the request/response being sent by the generated tests client?

The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

logging.level.org.apache.http.wire=DEBUG

3.7.1 How can I debug the mapping/request/response being sent by WireMock?

Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which matching response definition was picked.

To turn off this feature just bump WireMock logging to ERROR

logging.level.com.github.tomakehurst.wiremock=ERROR

3.7.2 How can I see what got registered in the HTTP server stub?

You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

3.7.3 Can I reference the request from the response?

Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support -for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

3.7.4 Can I reference text from file?

Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

3.7.3 Can I reference text from file?

Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. If you’re using YAML just use the bodyFromFile property.

Prev   Next
2. Spring Cloud Contract Verifier Introduction Home 4. Spring Cloud Contract Verifier Setup
\ No newline at end of file diff --git a/multi/multi__spring_cloud_contract_verifier_introduction.html b/multi/multi__spring_cloud_contract_verifier_introduction.html index 6d87f22e93..0188eb8087 100644 --- a/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -9,14 +9,14 @@ produced by Spring Cloud Contract Verifier.
  • Messaging r 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 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 +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, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    The following properties are used when you want to specify the location of the JAR +JUnit are supported with JUnit 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 groupid:artifactid:version:classifier coordinates. You can use the contractDependency @@ -184,7 +185,14 @@ baseClassMappings { - src/test/resources/contract/foo/

    By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You could also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    4.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    4.1.13 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    4.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    4.1.13 Pushing stubs to SCM

    If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to call the pushStubsToScm +task. Example:

    $ ./gradlew pushStubsToScm

    Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible +configuration options that you can pass either via +the contractsProperties field e.g. contracts { contractsProperties = [foo:"bar"] }, +via contractsProperties method e.g. contracts { contractsProperties([foo:"bar"]) }, +a system property or an environment variable.

    4.1.14 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you do not want to use Stub Runner then you need to copy contracts stored in src/test/resources/contracts and generate WireMock JSON stubs using:

    ./gradlew generateClientStubs
    [Note]Note

    The stubsOutputDir option has to be set for stub generation to work.

    When present, JSON stubs can be used in automated tests of consuming a service.

    @ContextConfiguration(loader == SpringApplicationContextLoader, classes == Application)
@@ -209,7 +217,7 @@ WireMock JSON stubs using:
    ./gradlew generateClie
  }
 }
    LoanApplication makes a call to FraudDetection service. This request is handled by a
 WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

    4.2 Maven Project

    To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the -following sections:

    4.2.1 Add maven plugin

    Add the Spring Cloud Contract BOM in a fashion similar to this:

    <dependencyManagement>
+following sections:
    4.2.1 Add maven plugin
    Add the Spring Cloud Contract BOM in a fashion similar to this:
    <dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -375,7 +383,8 @@ the matched contract. For example, if you have a contract under
 src/test/resources/contract/foo/bar/baz/ and map the property
 .* → com.example.base.BaseClass, then the test class generated from these contracts
 extends com.example.base.BaseClass. This setting takes precedence over
-packageWithBaseClasses and baseClassForTests.
    If you want to download your contract definitions from a Maven repository, you can use
+packageWithBaseClasses and baseClassForTests.
  • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
+components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders.

    • If you want to download your contract definitions from a Maven repository, you can use the following options:

    • contractDependency: The contract dependency that contains all the packaged contracts.
    • contractsPath: The path to the concrete contracts in the JAR with packaged contracts. Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsMode: Picks the mode in which stubs will be found and registered
    • contractsSnapshotCheckSkip: If true then will not assert whether a stub / contract JAR was downloaded from local or remote location
    • deleteStubsAfterTest: If set to false will not remove any downloaded @@ -497,7 +506,46 @@ goal.

      For Groovy Spock code, use the following:

      </testSources>
 	</configuration>
 </plugin>

      To ensure that provider side is compliant with defined contracts, you need to invoke -mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+mvn generateTest test.

    4.2.11 Pushing stubs to SCM

    If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to add the pushStubsToScm +goal. Example:

    <plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <version>${project.version}</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <executions>
+        <execution>
+            <phase>package</phase>
+            <goals>
+                <!-- By default we will not push the stubs back to SCM,
+                you have to explicitly add it as a goal -->
+                <goal>pushStubsToScm</goal>
+            </goals>
+        </execution>
+    </executions>
+</plugin>

    Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible +configuration options that you can pass either via +the <configuration><contractProperties> map, a system property +or an environment variable.

    4.2.12 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html
index 7fdb9e97bd..fcb8146c83 100644
--- a/multi/multi__using_the_pluggable_architecture.html
+++ b/multi/multi__using_the_pluggable_architecture.html
@@ -376,4 +376,20 @@ 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 (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 +If you provide more than one, then the first one on the list is used.

    10.6 Using the SCM Stub Downloader

    Whenever the repositoryRoot starts with a SCM protocol +(currently we support only git://), the stub downloader will try +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) +* 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) +* STUBRUNNER_PROPERTIES_GIT_USERNAME (env prop)

    		 

    Git clone username

    * git.password (plugin prop) +* stubrunner.properties.git.password (system prop) +* STUBRUNNER_PROPERTIES_GIT_PASSWORD (env prop)

    		 

    Git clone password

    * git.no-of-attempts (plugin prop) +* stubrunner.properties.git.no-of-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_NO_OF_ATTEMPTS (env prop)

    10

    Number of attempts to push the commits to origin

    * git.wait-between-attempts (Plugin prop) +* stubrunner.properties.git.wait-between-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    Prev   Next
    9. Customization Home 11. Spring Cloud Contract WireMock
    \ No newline at end of file diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html index fcaa8115ea..f1f4ca6e52 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.0.BUILD-SNAPSHOT

    Prev   Next
    Spring Cloud Contract Home 1. Spring Cloud Contract
    \ No newline at end of file +
    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.0.BUILD-SNAPSHOT

    Prev   Next
    Spring Cloud Contract Home 1. Spring Cloud Contract
    \ No newline at end of file diff --git a/multi/multi_spring-cloud-contract.html b/multi/multi_spring-cloud-contract.html index 7d5e91b369..a7341f3b71 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. 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. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.3. Stubs and Transitive Dependencies
    4.4. CI Server setup
    4.5. Scenarios
    4.6. Docker Project
    4.6.1. Short intro to Maven, JARs and Binary storage
    4.6.2. How it works
    Environment Variables
    4.6.3. Example of usage
    4.6.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    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. Messaging Top-Level Elements
    8.9.1. Output Triggered by a Method
    8.9.2. Output Triggered by a Message
    8.9.3. Consumer/Producer
    8.9.4. Common
    8.10. Multiple Contracts in One File
    9. Customization
    9.1. Extending the DSL
    9.1.1. Common JAR
    9.1.2. Adding the Dependency to the Project
    9.1.3. Test the Dependency in the Project’s Dependencies
    9.1.4. Test a Dependency in the Plugin’s Dependencies
    9.1.5. Referencing classes in DSLs
    10. Using the Pluggable Architecture
    10.1. Custom Contract Converter
    10.1.1. Pact Converter
    10.1.2. Pact Contract
    10.1.3. Pact for Producers
    10.1.4. Pact for Consumers
    10.2. Using the Custom Test Generator
    10.3. Using the Custom Stub Generator
    10.4. Using the Custom Stub Runner
    10.5. Using the Custom Stub Downloader
    11. Spring Cloud Contract WireMock
    11.1. Registering Stubs Automatically
    11.2. Using Files to Specify the Stub Bodies
    11.3. Alternative: Using JUnit Rules
    11.4. Relaxed SSL Validation for Rest Template
    11.5. WireMock and Spring MVC Mocks
    11.6. Customization of WireMock configuration
    11.7. Generating Stubs using REST Docs
    11.8. Generating Contracts by Using REST Docs
    12. Migrations
    12.1. 1.0.x → 1.1.x
    12.1.1. New structure of generated stubs
    12.2. 1.1.x → 1.2.x
    12.2.1. Custom HttpServerStub
    12.2.2. New packages for generated tests
    12.2.3. New Methods in TemplateProcessor
    12.2.4. RestAssured 3.0
    12.3. 1.2.x → 2.0.x
    12.3.1. No Camel support
    13. Links
       Next
       
    \ No newline at end of file + Spring Cloud Contract
    Spring Cloud Contract
       Next

    Spring Cloud Contract

    Table of Contents

    1. Spring Cloud Contract
    2. Spring Cloud Contract Verifier Introduction
    2.1. Why a Contract Verifier?
    2.1.1. Testing issues
    2.2. Purposes
    2.3. How It Works
    2.3.1. 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. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference 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. 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
    10.6. Using the SCM 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 36ed20e4ad..c35fd8bde0 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. Can I have multiple base classes for tests?
    3.7. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference the request from the response?
    3.7.4. Can I reference text from file?
    4. Spring Cloud Contract Verifier Setup
    4.1. Gradle Project
    4.1.1. Prerequisites
    4.1.2. Add Gradle Plugin with Dependencies
    4.1.3. Gradle and Rest Assured 2.0
    4.1.4. Snapshot Versions for Gradle
    4.1.5. Add stubs
    4.1.6. Run the Plugin
    4.1.7. Default Setup
    4.1.8. Configure Plugin
    4.1.9. Configuration Options
    4.1.10. Single Base Class for All Tests
    4.1.11. Different Base Classes for Contracts
    4.1.12. Invoking Generated Tests
    4.1.13. Spring Cloud Contract Verifier on the Consumer Side
    4.2. Maven Project
    4.2.1. Add maven plugin
    4.2.2. Maven and Rest Assured 2.0
    4.2.3. Snapshot versions for Maven
    4.2.4. Add stubs
    4.2.5. Run plugin
    4.2.6. Configure plugin
    4.2.7. Configuration Options
    4.2.8. Single Base Class for All Tests
    4.2.9. Different base classes for contracts
    4.2.10. Invoking generated tests
    4.2.11. Maven Plugin and STS
    4.3. Stubs and Transitive Dependencies
    4.4. CI Server setup
    4.5. Scenarios
    4.6. Docker Project
    4.6.1. Short intro to Maven, JARs and Binary storage
    4.6.2. How it works
    Environment Variables
    4.6.3. Example of usage
    4.6.4. Server side (nodejs)
    5. Spring Cloud Contract Verifier Messaging
    5.1. Integrations
    5.2. Manual Integration Testing
    5.3. Publisher-Side Test Generation
    5.3.1. Scenario 1: No Input Message
    5.3.2. Scenario 2: Output Triggered by Input
    5.3.3. Scenario 3: No Output Message
    5.4. Consumer Stub Generation
    6. Spring Cloud Contract Stub Runner
    6.1. Snapshot versions
    6.2. Publishing Stubs as JARs
    6.3. Stub Runner Core
    6.3.1. Retrieving stubs
    Stub downloading
    Classpath scanning
    6.3.2. Running stubs
    Limitations
    Running using main app
    HTTP Stubs
    Viewing registered mappings
    Messaging Stubs
    6.4. Stub Runner JUnit Rule
    6.4.1. Maven settings
    6.4.2. Providing fixed ports
    6.4.3. Fluent API
    6.4.4. Stub Runner with Spring
    6.5. Stub Runner Spring Cloud
    6.5.1. Stubbing Service Discovery
    Test profiles and service discovery
    6.5.2. Additional Configuration
    6.6. Stub Runner Boot Application
    6.6.1. How to use it?
    Stub Runner Server
    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. 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 + 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. How can I debug the request/response being sent by the generated tests client?
    3.7.1. How can I debug the mapping/request/response being sent by WireMock?
    3.7.2. How can I see what got registered in the HTTP server stub?
    3.7.3. Can I reference 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. 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
    10.6. Using the SCM 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), covering a range of options for writing tests, publishing them as assets, and asserting @@ -14,14 +14,14 @@ produced by Spring Cloud Contract Verifier.

  • Messaging r 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 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 +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, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.2 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both @@ -398,8 +398,8 @@ us. The current implementation of our system grants loans to everybody.

      As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.

      Technical remark - Fraud Detection has an artifact-id of http-server, while Loan Issuance has an artifact-id of http-client, and both have a group-id of com.example.

      Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.

      The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.

      The server +side code is available here and the client code here.

      [Tip]Tip

      In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.

      2.4.1 Technical note

      If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

      Maven.  @@ -781,9 +781,9 @@ achieving the same thing by changing the properties.

      spring-cloud-starter-contract-verifier.

      2.6 Additional Links

      Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under constant development.

      2.6.1 Spring Cloud Contract video

      You can check out the video from the Warsaw JUG about Spring Cloud Contract:

      2.6.2 Readings

      2.7 Samples

      You can find some samples at -samples.

    3. Spring Cloud Contract FAQ

    3.1 Why use Spring Cloud Contract Verifier and not X ?

    For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating +samples.

    3. Spring Cloud Contract FAQ

    3.1 Why use Spring Cloud Contract Verifier and not X ?

    For the time being Spring Cloud Contract is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make -Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

    • Possibility to do CDC with messaging
    • Clear and easy to use, statically typed DSL
    • Possibility to copy paste your current JSON file to the contract and only edit its elements
    • Automatic generation of tests from the defined Contract
    • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
    • Spring Cloud integration - no discovery service is needed for integration tests

    3.2 I don’t want to write a contract in Groovy!

    No problem. You can write a contract in YAML!

    3.3 What is this value(consumer(), producer()) ?

    One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. +Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

    • Possibility to do CDC with messaging
    • Clear and easy to use, statically typed DSL
    • Possibility to copy paste your current JSON file to the contract and only edit its elements
    • Automatic generation of tests from the defined Contract
    • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
    • Spring Cloud integration - no discovery service is needed for integration tests
    • Spring Cloud Contract integrates with Pact out of the box and provides easy hooks to extend its functionality
    • Via Docker adds support for any language & framework used

    3.2 I don’t want to write a contract in Groovy!

    No problem. You can write a contract in YAML!

    3.3 What is this value(consumer(), producer()) ?

    One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. What typically makes that difficult are the hard-coded values of request / response elements. For example dates or ids. Imagine the following JSON request

    {
     "time" : "2016-10-10 20:10:15",
@@ -863,7 +863,7 @@ It can be related to security issues where the consumers can’t clone the p
 contracts in a single place then you, as a producer, will know how many consumers you have and which
 consumer will you break with your local changes.
    3.5.1 Repo structure
    Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1,
 client2, client3. Then in the repository with common contracts you would have the following setup
-(which you can checkout here:
    ├── com
+(which you can checkout here):
    ├── com
 │   └── example
 │       └── server
 │           ├── client1
@@ -896,15 +896,15 @@ one to one to the contents of the repo.
    Example of a <parent>
 		<groupId>org.springframework.boot</groupId>
 		<artifactId>spring-boot-starter-parent</artifactId>
-		<version>1.5.10.RELEASE</version>
+		<version>2.0.0.BUILD-SNAPSHOT</version>
 		<relativePath />
 	</parent>
 
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>1.2.5.BUILD-SNAPSHOT</spring-cloud-contract.version>
-		<spring-cloud-dependencies.version>Edgware.BUILD-SNAPSHOT</spring-cloud-dependencies.version>
+		<spring-cloud-contract.version>2.0.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
 
@@ -1061,6 +1061,7 @@ of the JAR containing the contracts:
    <groupId>org.springframework.cloud</groupId>
 	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
 	<configuration>
+		<contractsMode>REMOTE</contractsMode>
 		<contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl>
 		<contractDependency>
 			<groupId>com.example.standalone</groupId>
@@ -1169,24 +1170,130 @@ configurations {
         include: "**/*",
         excludes: [
             "**/${project.name}/**"",
-            **/${first-topic}/**",
-            **/${second-topic}/**])
-}
    • Create task dependencies:
    unzipContracts.dependsOn("getContracts")
+            "**/${first-topic}/**",
+            "**/${second-topic}/**"])
+}
    • Create task dependencies:
    unzipContracts.dependsOn("getContracts")
 deleteUnwantedContracts.dependsOn("unzipContracts")
-build.dependsOn("deleteUnwantedContracts")
    • Configure plugin by specifying the directory containing contracts using contractsDslDir property
    contracts {
-
+build.dependsOn("deleteUnwantedContracts")
    • Configure plugin by specifying the directory containing contracts using contractsDslDir property
    contracts {
     contractsDslDir = new File("${buildDir}/unpackedContracts")
-}

    3.6 Can I have multiple base classes for tests?

    Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins.

    3.7 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    3.7.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to +}

    3.6 Do I need a Binary Storage? Can’t I use Git?

    In the polyglot world, there are languages that don’t use binary storages like +Artifactory or Nexus. Starting from Spring Cloud Contract version 2.0.0 we provide +mechanisms to store contracts and stubs in a SCM repository. Currently the +only supported SCM is Git.

    The repository would have to the following setup +(which you can checkout here):

    .
+└── META-INF
+    └── com.example
+        └── beer-api-producer-git
+            └── 0.0.1-SNAPSHOT
+                ├── contracts
+                │   └── beer-api-consumer
+                │       ├── messaging
+                │       │   ├── shouldSendAcceptedVerification.groovy
+                │       │   └── shouldSendRejectedVerification.groovy
+                │       └── rest
+                │           ├── shouldGrantABeerIfOldEnough.groovy
+                │           └── shouldRejectABeerIfTooYoung.groovy
+                └── mappings
+                    └── beer-api-consumer
+                        └── rest
+                            ├── shouldGrantABeerIfOldEnough.json
+                            └── shouldRejectABeerIfTooYoung.json

    Under META-INF folder:

    • we group applications via groupId (e.g. com.example)
    • then each application is represented via the artifactId (e.g. beer-api-producer-git)
    • next, the version of the application. The version is mandatory! (e.g. 0.0.1-SNAPSHOT)

    • finally, there are two folders:

      • contracts - the good practice is to store the contracts required by each +consumer in the folder with the consumer name (e.g. beer-api-consumer). That way you +can use the stubs-per-consumer feature. Further directory structure is arbitrary.
      • mappings - in this folder the Maven / Gradle Spring Cloud Contract plugins will push +the stub server mappings. On the consumer side, Stub Runner will scan this folder +to start stub servers with stub definitions. The folder structure will be a copy +of the one created in the contracts subfolder.

    3.6.1 Protocol convention

    In order to control the type and location of the source of contracts (whether it’s +a binary storage or an SCM repository), you can use the protocol in the URL of +the repository. Spring Cloud Contract iterates over registered protocol resolvers +and tries to fetch the contracts (via a plugin) or stubs (via Stub Runner).

    For the SCM functionality, currently, we support the Git repository. To use it, +in the property, where the repository URL needs to be placed you just have to prefix +the connection URL with git://. Here you can find a couple of examples:

    git://file:///foo/bar
+git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git
+git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git

    3.6.2 Producer

    For the producer, to use the SCM approach, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the SCM implementation via the URL that contains +the git:// protocol.

    [Important]Important

    You have to manually add the pushStubsToScm +goal in Maven or execute (bind) the pushStubsToScm task in +Gradle. We don’t push stubs to origin of your git +repository out of the box.

    Maven.  +

    <plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <version>${project.version}</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <executions>
+        <execution>
+            <phase>package</phase>
+            <goals>
+                <!-- By default we will not push the stubs back to SCM,
+                you have to explicitly add it as a goal -->
+                <goal>pushStubsToScm</goal>
+            </goals>
+        </execution>
+    </executions>
+</plugin>

    +

    Gradle.  +

    contracts {
+	// We want to pick contracts from a Git repository
+	contractDependency {
+		stringNotation = "${project.group}:${project.name}:${project.version}"
+	}
+	/*
+	We reuse the contract dependency section to set up the path
+	to the folder that contains the contract definitions. In our case the
+	path will be /groupId/artifactId/version/contracts
+	 */
+	contractRepository {
+		repositoryUrl = "git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git"
+	}
+	// The mode can't be classpath
+	contractsMode = "REMOTE"
+	// Base class mappings etc.
+}
+
+/*
+In this scenario we want to publish stubs to SCM whenever
+the `publish` task is executed
+*/
+publish.dependsOn("publishStubsToScm")

    +

    With such a setup:

    • Git project will be cloned to a temporary directory
    • The SCM stub downloader will go to META-INF/groupId/artifactId/version/contracts folder +to find contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/contracts
    • Tests will be generated from the contracts
    • Stubs will be created from the contracts
    • Once the tests pass, the stubs will be committed in the cloned repository
    • Finally, a push will be done to that repo’s origin

    3.6.3 Consumer

    On the consumer side when passing the repositoryRoot parameter, +either from the @AutoConfigureStubRunner annotation, the +JUnit rule or properties, it’s enough to pass the URL of the +SCM repository, prefixed with the protocol. For example

    @AutoConfigureStubRunner(
+    stubsMode="REMOTE",
+    repositoryRoot="git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git",
+    ids="com.example:bookstore:0.0.1.RELEASE"
+)

    With such a setup:

    • Git project will be cloned to a temporary directory
    • The SCM stub downloader will go to META-INF/groupId/artifactId/version/ folder +to find stub definitions and contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/
    • Stub servers will be started and fed with mappings
    • Messaging definitions will be read and used in the messaging tests

    3.7 How can I debug the request/response being sent by the generated tests client?

    The generated tests all boil down to RestAssured in some form or fashion which relies on Apache HttpClient. HttpClient has a facility called wire logging which logs the entire request and response to HttpClient. Spring Boot has a logging common application property for doing this sort of thing, just add this to your application properties

    logging.level.org.apache.http.wire=DEBUG

    3.7.1 How can I debug the mapping/request/response being sent by WireMock?

    Starting from version 1.2.0 we turn on WireMock logging to info and the WireMock notifier to being verbose. Now you will exactly know what request was received by WireMock server and which matching response definition was picked.

    To turn off this feature just bump WireMock logging to ERROR

    logging.level.com.github.tomakehurst.wiremock=ERROR

    3.7.2 How can I see what got registered in the HTTP server stub?

    You can use the mappingsOutputFolder property on @AutoConfigureStubRunner or StubRunnerRule to dump all mappings per artifact id. Also the port at which the given stub server was -started will be attached.

    3.7.3 Can I reference the request from the response?

    Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support -for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself.

    3.7.4 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the +started will be attached.

    3.7.3 Can I reference text from file?

    Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the DSL and provide a path relative to where the contract lays. If you’re using YAML just use the bodyFromFile property.

    4. Spring Cloud Contract Verifier Setup

    You can set up Spring Cloud Contract Verifier in the following ways:

    4.1 Gradle Project

    To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the -following sections:

    4.1.1 Prerequisites

    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a +following sections:

    4.1.1 Prerequisites

    In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a Gradle or a Maven plugin.

    [Warning]Warning

    If you want to use Spock in your projects, you must add separately the spock-core and spock-spring modules. Check Spock docs for more information

    4.1.2 Add Gradle Plugin with Dependencies

    To add a Gradle plugin with dependencies, use code similar to this:

    buildscript {
@@ -1318,7 +1425,8 @@ GroovyDSL. By default, its value is $rootDir/src/test/reso
 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.

    • The following properties are used when you want to specify the location of the JAR +JUnit are supported with JUnit 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 groupid:artifactid:version:classifier coordinates. You can use the contractDependency @@ -1369,7 +1477,14 @@ baseClassMappings { - src/test/resources/contract/foo/

    By providing the baseClassForTests, we have a fallback in case mapping did not succeed. (You could also provide the packageWithBaseClasses as a fallback.) That way, the tests generated from src/test/resources/contract/com/ contracts extend the -com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    4.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    4.1.13 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin +com.example.ComBase, whereas the rest of the tests extend com.example.FooBase.

    4.1.12 Invoking Generated Tests

    To ensure that the provider side is compliant with defined contracts, you need to invoke:

    ./gradlew generateContractTests test

    4.1.13 Pushing stubs to SCM

    If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to call the pushStubsToScm +task. Example:

    $ ./gradlew pushStubsToScm

    Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible +configuration options that you can pass either via +the contractsProperties field e.g. contracts { contractsProperties = [foo:"bar"] }, +via contractsProperties method e.g. contracts { contractsProperties([foo:"bar"]) }, +a system property or an environment variable.

    4.1.14 Spring Cloud Contract Verifier on the Consumer Side

    In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin in exactly the same way as in case of provider. If you do not want to use Stub Runner then you need to copy contracts stored in src/test/resources/contracts and generate WireMock JSON stubs using:

    ./gradlew generateClientStubs
    [Note]Note

    The stubsOutputDir option has to be set for stub generation to work.

    When present, JSON stubs can be used in automated tests of consuming a service.

    @ContextConfiguration(loader == SpringApplicationContextLoader, classes == Application)
@@ -1394,7 +1509,7 @@ WireMock JSON stubs using:
    ./gradlew generateClie
  }
 }
    LoanApplication makes a call to FraudDetection service. This request is handled by a
 WireMock server configured with stubs generated by Spring Cloud Contract Verifier.

    4.2 Maven Project

    To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the -following sections:

    4.2.1 Add maven plugin

    Add the Spring Cloud Contract BOM in a fashion similar to this:

    <dependencyManagement>
+following sections:
    4.2.1 Add maven plugin
    Add the Spring Cloud Contract BOM in a fashion similar to this:
    <dependencyManagement>
 	<dependencies>
 		<dependency>
 			<groupId>org.springframework.cloud</groupId>
@@ -1560,7 +1675,8 @@ the matched contract. For example, if you have a contract under
 src/test/resources/contract/foo/bar/baz/ and map the property
 .* → com.example.base.BaseClass, then the test class generated from these contracts
 extends com.example.base.BaseClass. This setting takes precedence over
-packageWithBaseClasses and baseClassForTests.
    If you want to download your contract definitions from a Maven repository, you can use
+packageWithBaseClasses and baseClassForTests.
  • contractsProperties: a map containing properties to be passed to Spring Cloud Contract
+components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders.

    • If you want to download your contract definitions from a Maven repository, you can use the following options:

    • contractDependency: The contract dependency that contains all the packaged contracts.
    • contractsPath: The path to the concrete contracts in the JAR with packaged contracts. Defaults to groupid/artifactid where gropuid is slash separated.
    • contractsMode: Picks the mode in which stubs will be found and registered
    • contractsSnapshotCheckSkip: If true then will not assert whether a stub / contract JAR was downloaded from local or remote location
    • deleteStubsAfterTest: If set to false will not remove any downloaded @@ -1682,7 +1798,46 @@ goal.

      For Groovy Spock code, use the following:

      </testSources>
 	</configuration>
 </plugin>

      To ensure that provider side is compliant with defined contracts, you need to invoke -mvn generateTest test.

    4.2.11 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+mvn generateTest test.

    4.2.11 Pushing stubs to SCM

    If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to add the pushStubsToScm +goal. Example:

    <plugin>
+    <groupId>org.springframework.cloud</groupId>
+    <artifactId>spring-cloud-contract-maven-plugin</artifactId>
+    <version>${spring-cloud-contract.version}</version>
+    <extensions>true</extensions>
+    <configuration>
+        <!-- Base class mappings etc. -->
+
+        <!-- We want to pick contracts from a Git repository -->
+        <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl>
+
+        <!-- We reuse the contract dependency section to set up the path
+        to the folder that contains the contract definitions. In our case the
+        path will be /groupId/artifactId/version/contracts -->
+        <contractDependency>
+            <groupId>${project.groupId}</groupId>
+            <artifactId>${project.artifactId}</artifactId>
+            <version>${project.version}</version>
+        </contractDependency>
+
+        <!-- The contracts mode can't be classpath -->
+        <contractsMode>REMOTE</contractsMode>
+    </configuration>
+    <executions>
+        <execution>
+            <phase>package</phase>
+            <goals>
+                <!-- By default we will not push the stubs back to SCM,
+                you have to explicitly add it as a goal -->
+                <goal>pushStubsToScm</goal>
+            </goals>
+        </execution>
+    </executions>
+</plugin>

    Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible +configuration options that you can pass either via +the <configuration><contractProperties> map, a system property +or an environment variable.

    4.2.12 Maven Plugin and STS

    If you see the following exception while using STS:

    STS Exception

    When you click on the error marker you should see something like this:

     plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
@@ -5443,7 +5598,23 @@ 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 (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 +If you provide more than one, then the first one on the list is used.

    10.6 Using the SCM Stub Downloader

    Whenever the repositoryRoot starts with a SCM protocol +(currently we support only git://), the stub downloader will try +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) +* 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) +* STUBRUNNER_PROPERTIES_GIT_USERNAME (env prop)

    		 

    Git clone username

    * git.password (plugin prop) +* stubrunner.properties.git.password (system prop) +* STUBRUNNER_PROPERTIES_GIT_PASSWORD (env prop)

    		 

    Git clone password

    * git.no-of-attempts (plugin prop) +* stubrunner.properties.git.no-of-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_NO_OF_ATTEMPTS (env prop)

    10

    Number of attempts to push the commits to origin

    * git.wait-between-attempts (Plugin prop) +* stubrunner.properties.git.wait-between-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop)

    1000

    Number of millis to wait between attempts to push the commits to origin


    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 @@ -5749,7 +5920,8 @@ Contract.make { } } }

    The generated document (formatted in Asciidoc in this case) contains a formatted -contract. The location of this file would be index/dsl-contract.adoc.

    12. Migrations

    This section covers migrating from one version of Spring Cloud Contract Verifier to the +contract. The location of this file would be index/dsl-contract.adoc.

    12. Migrations

    [Tip]Tip

    For up to date migration guides please visit +the project’s wiki page.

    This section covers migrating from one version of Spring Cloud Contract Verifier to the next version. It covers the following versions upgrade paths:

    12.1 1.0.x → 1.1.x

    This section covers upgrading from version 1.0 to version 1.1.

    12.1.1 New structure of generated stubs

    In 1.1.x we have introduced a change to the structure of generated stubs. If you have been using the @AutoConfigureWireMock notation to use the stubs from the classpath, it no longer works. The following example shows how the @AutoConfigureWireMock notation diff --git a/spring-cloud-contract-maven-plugin/checkstyle.html b/spring-cloud-contract-maven-plugin/checkstyle.html index 98a69961c1..4241563873 100644 --- a/spring-cloud-contract-maven-plugin/checkstyle.html +++ b/spring-cloud-contract-maven-plugin/checkstyle.html @@ -282,7 +282,7 @@  Warnings  Errors -11 +12 0 0 0

    diff --git a/spring-cloud-contract-maven-plugin/checkstyle.rss b/spring-cloud-contract-maven-plugin/checkstyle.rss index 020bd4c53e..32043763e5 100644 --- a/spring-cloud-contract-maven-plugin/checkstyle.rss +++ b/spring-cloud-contract-maven-plugin/checkstyle.rss @@ -25,7 +25,7 @@ under the License. en-us ©2016 - 2018 Spring - File: 11, + <title>File: 12, Errors: 0, Warnings: 0, Infos: 0 @@ -99,6 +99,20 @@ under the License. <td> 0 </td> + </tr> + <tr> + <td> + <a href="https://github.com/spring-cloud/spring-cloud-contract/checkstyle.html#org.springframework.cloud.contract.maven.verifier.PushStubsToScmMojo.java">org/springframework/cloud/contract/maven/verifier/PushStubsToScmMojo.java</a> + </td> + <td> + 0 + </td> + <td> + 0 + </td> + <td> + 0 + </td> </tr> <tr> <td> @@ -116,7 +130,7 @@ under the License. </tr> <tr> <td> - <a href="https://github.com/spring-cloud/spring-cloud-contract/checkstyle.html#org.springframework.cloud.contract.maven.verifier.RunMojo.java">org/springframework/cloud/contract/maven/verifier/RunMojo.java</a> + <a href="https://github.com/spring-cloud/spring-cloud-contract/checkstyle.html#org.springframework.cloud.contract.maven.verifier.stubrunner.RemoteStubRunner.java">org/springframework/cloud/contract/maven/verifier/stubrunner/RemoteStubRunner.java</a> </td> <td> 0 @@ -144,7 +158,7 @@ under the License. </tr> <tr> <td> - <a href="https://github.com/spring-cloud/spring-cloud-contract/checkstyle.html#org.springframework.cloud.contract.maven.verifier.stubrunner.RemoteStubRunner.java">org/springframework/cloud/contract/maven/verifier/stubrunner/RemoteStubRunner.java</a> + <a href="https://github.com/spring-cloud/spring-cloud-contract/checkstyle.html#org.springframework.cloud.contract.maven.verifier.RunMojo.java">org/springframework/cloud/contract/maven/verifier/RunMojo.java</a> </td> <td> 0 diff --git a/spring-cloud-contract-maven-plugin/convert-mojo.html b/spring-cloud-contract-maven-plugin/convert-mojo.html index fbf2b3d8d5..94877179b5 100644 --- a/spring-cloud-contract-maven-plugin/convert-mojo.html +++ b/spring-cloud-contract-maven-plugin/convert-mojo.html @@ -349,6 +349,18 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <tr class="b"> +<td><b><a href="#contractsProperties">contractsProperties</a></b></td> + +<td><tt>Map</tt></td> + +<td><tt>-</tt></td> + +<td>Map of properties that can be passed to custom +<tt>StubDownloaderBuilder</tt><br /><b>User property is</b>: <tt>contractsProperties</tt>.<br /></td> + </tr> + +<tr class="a"> + <td><b><a href="#contractsRepositoryPassword">contractsRepositoryPassword</a></b></td> <td><tt>String</tt></td> @@ -358,7 +370,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The password to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryPassword</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsRepositoryProxyHost">contractsRepositoryProxyHost</a></b></td> @@ -369,7 +381,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The proxy host to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryProxyHost</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#contractsRepositoryProxyPort">contractsRepositoryProxyPort</a></b></td> @@ -380,7 +392,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The proxy port to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryProxyPort</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsRepositoryUrl">contractsRepositoryUrl</a></b></td> @@ -394,7 +406,7 @@ was provided then the current Maven's build repositories will be taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUrl</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#contractsRepositoryUsername">contractsRepositoryUsername</a></b></td> @@ -405,7 +417,7 @@ taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUr <td>The user name to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryUsername</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsSnapshotCheckSkip">contractsSnapshotCheckSkip</a></b></td> @@ -417,7 +429,7 @@ taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUr JAR was downloaded from local or remote location<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>contractsSnapshotCheckSkip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#deleteStubsAfterTest">deleteStubsAfterTest</a></b></td> @@ -429,7 +441,7 @@ JAR was downloaded from local or remote location<br /><b>Default value is</b>: < folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b>User property is</b>: <tt>deleteStubsAfterTest</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#destination">destination</a></b></td> @@ -440,7 +452,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>(no description)<br /><b>Default value is</b>: <tt>${basedir}</tt>.<br /><b>User property is</b>: <tt>stubsDirectory</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#excludeBuildFolders">excludeBuildFolders</a></b></td> @@ -453,7 +465,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> further processing.<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>excludeBuildFolders</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#skip">skip</a></b></td> @@ -464,7 +476,7 @@ further processing.<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User p <td>(no description)<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>spring.cloud.contract.verifier.skip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#source">source</a></b></td> @@ -478,7 +490,7 @@ further processing.<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User p maven project.</p><br /><b>Default value is</b>: <tt>${basedir}</tt>.<br /><b>User property is</b>: <tt>contractsDirectory</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#stubsDirectory">stubsDirectory</a></b></td> @@ -555,6 +567,19 @@ path will be <tt>/com/example/artifactid</tt></div> <li><b>User Property</b>: <tt>contractsPath</tt></li> </ul><hr /> +<p><b><a name="contractsProperties">contractsProperties</a>:</b></p> + +<div>Map of properties that can be passed to custom +<tt>StubDownloaderBuilder</tt></div> + +<ul> + +<li><b>Type</b>: <tt>java.util.Map</tt></li> + +<li><b>Required</b>: <tt>No</tt></li> + +<li><b>User Property</b>: <tt>contractsProperties</tt></li> + </ul><hr /> <p><b><a name="contractsRepositoryPassword">contractsRepositoryPassword</a>:</b></p> <div>The password to be used to connect to the repo with contracts.</div> diff --git a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html index 4c74a9efb4..c9f1200850 100644 --- a/spring-cloud-contract-maven-plugin/generateStubs-mojo.html +++ b/spring-cloud-contract-maven-plugin/generateStubs-mojo.html @@ -297,17 +297,6 @@ to be executed first</div> <tr class="b"> -<td><b><a href="#attachContracts">attachContracts</a></b></td> - -<td><tt>boolean</tt></td> - -<td><tt>-</tt></td> - -<td>(no description)<br /><b>Default value is</b>: <tt>true</tt>.<br /></td> - </tr> - -<tr class="a"> - <td><b><a href="#classifier">classifier</a></b></td> <td><tt>String</tt></td> @@ -317,7 +306,7 @@ to be executed first</div> <td>(no description)<br /><b>Default value is</b>: <tt>stubs</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#excludedFiles">excludedFiles</a></b></td> @@ -328,7 +317,7 @@ to be executed first</div> <td>Patterns that should not be taken into account for processing<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#jarSkip">jarSkip</a></b></td> @@ -339,7 +328,7 @@ to be executed first</div> <td>Set this to "true" to bypass only JAR creation<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>spring.cloud.contract.verifier.jar.skip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#outputDirectory">outputDirectory</a></b></td> @@ -350,7 +339,7 @@ to be executed first</div> <td>(no description)<br /><b>Default value is</b>: <tt>${project.build.directory}/stubs</tt>.<br /><b>User property is</b>: <tt>stubsDirectory</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#skip">skip</a></b></td> @@ -366,18 +355,6 @@ to be executed first</div> <div class="section"> <h3><a name="Parameter_Details"></a>Parameter Details</h3> -<p><b><a name="attachContracts">attachContracts</a>:</b></p> - -<div>(no description)</div> - -<ul> - -<li><b>Type</b>: <tt>boolean</tt></li> - -<li><b>Required</b>: <tt>No</tt></li> - -<li><b>Default</b>: <tt>true</tt></li> - </ul><hr /> <p><b><a name="classifier">classifier</a>:</b></p> <div>(no description)</div> diff --git a/spring-cloud-contract-maven-plugin/generateTests-mojo.html b/spring-cloud-contract-maven-plugin/generateTests-mojo.html index 9473d73f06..a826604e65 100644 --- a/spring-cloud-contract-maven-plugin/generateTests-mojo.html +++ b/spring-cloud-contract-maven-plugin/generateTests-mojo.html @@ -405,6 +405,18 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <tr class="b"> +<td><b><a href="#contractsProperties">contractsProperties</a></b></td> + +<td><tt>Map</tt></td> + +<td><tt>-</tt></td> + +<td>Map of properties that can be passed to custom +<tt>StubDownloaderBuilder</tt><br /><b>User property is</b>: <tt>contractsProperties</tt>.<br /></td> + </tr> + +<tr class="a"> + <td><b><a href="#contractsRepositoryPassword">contractsRepositoryPassword</a></b></td> <td><tt>String</tt></td> @@ -414,7 +426,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The password to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryPassword</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsRepositoryProxyHost">contractsRepositoryProxyHost</a></b></td> @@ -425,7 +437,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The proxy host to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryProxyHost</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#contractsRepositoryProxyPort">contractsRepositoryProxyPort</a></b></td> @@ -436,7 +448,7 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td>The proxy port to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryProxyPort</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsRepositoryUrl">contractsRepositoryUrl</a></b></td> @@ -444,13 +456,13 @@ path will be <tt>/com/example/artifactid</tt><br /><b>User property is</b>: <tt> <td><tt>-</tt></td> -<td>The URL from which a JAR containing the contracts should get -downloaded. If not provided but artifactid / coordinates notation -was provided then the current Maven's build repositories will be -taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUrl</tt>.<br /></td> +<td>The URL from which a contracts should get downloaded. If not +provided but artifactid / coordinates notation was provided then +the current Maven's build repositories will be taken into +consideration<br /><b>User property is</b>: <tt>contractsRepositoryUrl</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#contractsRepositoryUsername">contractsRepositoryUsername</a></b></td> @@ -461,7 +473,7 @@ taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUr <td>The user name to be used to connect to the repo with contracts.<br /><b>User property is</b>: <tt>contractsRepositoryUsername</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#contractsSnapshotCheckSkip">contractsSnapshotCheckSkip</a></b></td> @@ -473,7 +485,7 @@ taken into consideration<br /><b>User property is</b>: <tt>contractsRepositoryUr JAR was downloaded from local or remote location<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>contractsSnapshotCheckSkip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#deleteStubsAfterTest">deleteStubsAfterTest</a></b></td> @@ -485,7 +497,7 @@ JAR was downloaded from local or remote location<br /><b>Default value is</b>: < folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b>User property is</b>: <tt>deleteStubsAfterTest</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#excludedFiles">excludedFiles</a></b></td> @@ -496,7 +508,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>Patterns that should not be taken into account for processing<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#generatedTestSourcesDir">generatedTestSourcesDir</a></b></td> @@ -507,7 +519,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>(no description)<br /><b>Default value is</b>: <tt>${project.build.directory}/generated-test-sources/contracts</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#ignoredFiles">ignoredFiles</a></b></td> @@ -519,7 +531,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> @Ignored tests<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#imports">imports</a></b></td> @@ -530,7 +542,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>Imports that should be added to generated tests<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#mavenTestSkip">mavenTestSkip</a></b></td> @@ -541,7 +553,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>(no description)<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>maven.test.skip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#nameSuffixForTests">nameSuffixForTests</a></b></td> @@ -552,7 +564,7 @@ folder after running tests<br /><b>Default value is</b>: <tt>true</tt>.<br /><b> <td>(no description)<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#packageWithBaseClasses">packageWithBaseClasses</a></b></td> @@ -571,7 +583,7 @@ test source file that will have the package last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</b>: <tt>packageWithBaseClasses</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#ruleClassForTests">ruleClassForTests</a></b></td> @@ -582,7 +594,7 @@ last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</ <td>(no description)<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#skip">skip</a></b></td> @@ -593,7 +605,7 @@ last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</ <td>(no description)<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>spring.cloud.contract.verifier.skip</tt>.<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#skipTests">skipTests</a></b></td> @@ -604,7 +616,7 @@ last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</ <td>(no description)<br /><b>Default value is</b>: <tt>false</tt>.<br /><b>User property is</b>: <tt>skipTests</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#staticImports">staticImports</a></b></td> @@ -615,7 +627,7 @@ last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</ <td>Static imports that should be added to generated tests<br /></td> </tr> -<tr class="b"> +<tr class="a"> <td><b><a href="#testFramework">testFramework</a></b></td> @@ -626,7 +638,7 @@ last folders to and attach <tt>Base</tt> to its name.<br /><b>User property is</ <td>(no description)<br /><b>Default value is</b>: <tt>JUNIT</tt>.<br /></td> </tr> -<tr class="a"> +<tr class="b"> <td><b><a href="#testMode">testMode</a></b></td> @@ -758,6 +770,19 @@ path will be <tt>/com/example/artifactid</tt></div> <li><b>User Property</b>: <tt>contractsPath</tt></li> </ul><hr /> +<p><b><a name="contractsProperties">contractsProperties</a>:</b></p> + +<div>Map of properties that can be passed to custom +<tt>StubDownloaderBuilder</tt></div> + +<ul> + +<li><b>Type</b>: <tt>java.util.Map</tt></li> + +<li><b>Required</b>: <tt>No</tt></li> + +<li><b>User Property</b>: <tt>contractsProperties</tt></li> + </ul><hr /> <p><b><a name="contractsRepositoryPassword">contractsRepositoryPassword</a>:</b></p> <div>The password to be used to connect to the repo with contracts.</div> @@ -796,10 +821,10 @@ path will be <tt>/com/example/artifactid</tt></div> </ul><hr /> <p><b><a name="contractsRepositoryUrl">contractsRepositoryUrl</a>:</b></p> -<div>The URL from which a JAR containing the contracts should get -downloaded. If not provided but artifactid / coordinates notation -was provided then the current Maven's build repositories will be -taken into consideration</div> +<div>The URL from which a contracts should get downloaded. If not +provided but artifactid / coordinates notation was provided then +the current Maven's build repositories will be taken into +consideration</div> <ul> diff --git a/spring-cloud-contract-maven-plugin/plugin-info.html b/spring-cloud-contract-maven-plugin/plugin-info.html index 28d872e2fb..ae587f6544 100644 --- a/spring-cloud-contract-maven-plugin/plugin-info.html +++ b/spring-cloud-contract-maven-plugin/plugin-info.html @@ -296,6 +296,10 @@ spring-cloud-contract-maven-plugin.<br /> Call <code>mvn spring-cloud-contract:help -Ddetail=true -Dgoal=<goal-name></code> to display parameter details.</td></tr> <tr class="b"> +<td><a href="pushStubsToScm-mojo.html">spring-cloud-contract:pushStubsToScm</a></td> +<td>The generated stubs get committed to the SCM repo and pushed to +origin.</td></tr> +<tr class="a"> <td><a href="run-mojo.html">spring-cloud-contract:run</a></td> <td>No description.</td></tr></table> <div class="section"> diff --git a/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html b/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html new file mode 100644 index 0000000000..4d2dda1da8 --- /dev/null +++ b/spring-cloud-contract-maven-plugin/pushStubsToScm-mojo.html @@ -0,0 +1,551 @@ +<!DOCTYPE html> +<!-- + | Generated by Apache Maven Doxia Site Renderer 1.6 at 2018-03-31 + | Rendered using Apache Maven Fluido Skin 1.5 +--> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> + <head> + <meta charset="UTF-8" /> + <meta name="viewport" content="width=device-width, initial-scale=1.0" /> + <meta name="Date-Revision-yyyymmdd" content="20180331" /> + <meta http-equiv="Content-Language" content="en" /> + <title>Spring Cloud Contract Maven Plugin – spring-cloud-contract:pushStubsToScm + + + + + + + + + + + + + + + + + Fork me on GitHub + + + + + + +
    +
    +
    + + + + + + + + + + + +
    + +
    +
    +
    + +
    + + + + + +
    +
    +
    + + + + +
    + +
    +
    +
    +
    +
    + + Built by Maven + +
    +
    +
    + + +
    + + + +
    +

    spring-cloud-contract:pushStubsToScm

    + +

    Full name:

    + +

    org.springframework.cloud:spring-cloud-contract-maven-plugin:2.0.0.BUILD-SNAPSHOT:pushStubsToScm

    + +

    Description:

    + +
    The generated stubs get committed to the SCM repo and pushed to +origin.
    + +

    Attributes:

    + +
      + +
    • Requires a Maven project to be executed.
      • +
    + +
    +

    Optional Parameters

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameTypeSinceDescription
    contractsModeStubRunnerProperties$StubsMode-Picks the mode in which stubs will be found and registered
    Default value is: CLASSPATH.
    User property is: contractsMode.
    contractsPropertiesMap-Map of properties that can be passed to custom +StubDownloaderBuilder
    User property is: contractsProperties.
    contractsRepositoryPasswordString-The password to be used to connect to the repo with contracts.
    User property is: contractsRepositoryPassword.
    contractsRepositoryUrlString-The URL from which a contracts should get downloaded. If not +provided but artifactid / coordinates notation was provided then +the current Maven's build repositories will be taken into +consideration
    User property is: contractsRepositoryUrl.
    contractsRepositoryUsernameString-The user name to be used to connect to the repo with contracts.
    User property is: contractsRepositoryUsername.
    deleteStubsAfterTestboolean-If set to false will NOT delete stubs from a temporary +folder after running tests
    Default value is: true.
    User property is: deleteStubsAfterTest.
    outputDirectoryFile-(no description)
    Default value is: ${project.build.directory}/stubs.
    User property is: stubsDirectory.
    skipboolean-Set this to "true" to bypass the whole Verifier execution
    Default value is: false.
    User property is: spring.cloud.contract.verifier.skip.
    taskSkipboolean-Set this to "true" to bypass only JAR creation
    Default value is: false.
    User property is: spring.cloud.contract.verifier.publish-stubs-to-scm.skip.
    +
    + +
    +

    Parameter Details

    + +

    contractsMode:

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

    contractsProperties:

    + +
    Map of properties that can be passed to custom +StubDownloaderBuilder
    + +
      + +
    • Type: java.util.Map
      • + +
    • Required: No
      • + +
    • User Property: contractsProperties
      • +
    +

    contractsRepositoryPassword:

    + +
    The password to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.String
      • + +
    • Required: No
      • + +
    • User Property: contractsRepositoryPassword
      • +
    +

    contractsRepositoryUrl:

    + +
    The URL from which a contracts should get downloaded. If not +provided but artifactid / coordinates notation was provided then +the current Maven's build repositories will be taken into +consideration
    + +
      + +
    • Type: java.lang.String
      • + +
    • Required: No
      • + +
    • User Property: contractsRepositoryUrl
      • +
    +

    contractsRepositoryUsername:

    + +
    The user name to be used to connect to the repo with contracts.
    + +
      + +
    • Type: java.lang.String
      • + +
    • Required: No
      • + +
    • User Property: contractsRepositoryUsername
      • +
    +

    deleteStubsAfterTest:

    + +
    If set to false will NOT delete stubs from a temporary +folder after running tests
    + +
      + +
    • Type: boolean
      • + +
    • Required: No
      • + +
    • User Property: deleteStubsAfterTest
      • + +
    • Default: true
      • +
    +

    outputDirectory:

    + +
    (no description)
    + +
      + +
    • Type: java.io.File
      • + +
    • Required: No
      • + +
    • User Property: stubsDirectory
      • + +
    • Default: ${project.build.directory}/stubs
      • +
    +

    skip:

    + +
    Set this to "true" to bypass the whole Verifier execution
    + +
      + +
    • Type: boolean
      • + +
    • Required: No
      • + +
    • User Property: spring.cloud.contract.verifier.skip
      • + +
    • Default: false
      • +
    +

    taskSkip:

    + +
    Set this to "true" to bypass only JAR creation
    + +
      + +
    • Type: boolean
      • + +
    • Required: No
      • + +
    • User Property: spring.cloud.contract.verifier.publish-stubs-to-scm.skip
      • + +
    • Default: false
      • +
    +
    +
    + + +
    +
    +
    + +
    + +
    +
    +
    +

    Copyright © 2016–2018 + Spring. + All rights reserved. +

    +
    + + +
    +
    + + diff --git a/spring-cloud-contract.xml b/spring-cloud-contract.xml index 8389d7af88..7ffa8f0d08 100644 --- a/spring-cloud-contract.xml +++ b/spring-cloud-contract.xml @@ -8,8 +8,8 @@ -_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 +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 @@ -53,7 +53,7 @@ Spring Cloud Contract Verifier. - + Microservices Architecture @@ -128,7 +128,7 @@ are those that your application directly uses. - + Stubbed Services @@ -710,8 +710,8 @@ we mark the client as a fraud. Issuance has an artifact-id of http-client, and both have a group-id of com.example. Social remark - both client and server development teams need to communicate directly and discuss changes while going through the process. CDC is all about communication. -The server -side code is available here and the +The server +side code is available here and the client code here. In this case, the producer owns the contracts. Physically, all the contract are @@ -1329,7 +1329,7 @@ constant development. Spring Cloud Contract FAQ
    Why use Spring Cloud Contract Verifier and not X ? -For the time being Spring Cloud Contract Verifier is a JVM based tool. So it could be your first pick when you’re already creating +For the time being Spring Cloud Contract is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are: @@ -1351,6 +1351,12 @@ Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Cont Spring Cloud integration - no discovery service is needed for integration tests + +Spring Cloud Contract integrates with Pact out of the box and provides easy hooks to extend its functionality + + +Via Docker adds support for any language & framework used +
    @@ -1512,7 +1518,7 @@ consumer will you break with your local changes. Repo structure Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup -(which you can checkout here: +(which you can checkout here): ├── com │   └── example │   └── server @@ -1549,15 +1555,15 @@ one to one to the contents of the repo. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>1.5.10.RELEASE</version> + <version>2.0.0.BUILD-SNAPSHOT</version> <relativePath /> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>1.2.5.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-dependencies.version>Edgware.BUILD-SNAPSHOT</spring-cloud-dependencies.version> + <spring-cloud-contract.version>2.0.0.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-dependencies.version>Finchley.BUILD-SNAPSHOT</spring-cloud-dependencies.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -1735,6 +1741,7 @@ of the JAR containing the contracts: <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-contract-maven-plugin</artifactId> <configuration> + <contractsMode>REMOTE</contractsMode> <contractsRepositoryUrl>http://link/to/your/nexus/or/artifactory/or/sth</contractsRepositoryUrl> <contractDependency> <groupId>com.example.standalone</groupId> @@ -1909,8 +1916,8 @@ configurations { include: "**/*", excludes: [ "**/${project.name}/**"", - **/${first-topic}/**", - **/${second-topic}/**]) + "**/${first-topic}/**", + "**/${second-topic}/**"]) } @@ -1922,20 +1929,214 @@ deleteUnwantedContracts.dependsOn("unzipContracts") build.dependsOn("deleteUnwantedContracts") -Configure plugin by specifying the directory containing contracts using contractsDslDir property +Configure plugin by specifying the directory containing contracts using contractsDslDir property contracts { - contractsDslDir = new File("${buildDir}/unpackedContracts") }
    -
    -Can I have multiple base classes for tests? -Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins. +
    +Do I need a Binary Storage? Can’t I use Git? +In the polyglot world, there are languages that don’t use binary storages like +Artifactory or Nexus. Starting from Spring Cloud Contract version 2.0.0 we provide +mechanisms to store contracts and stubs in a SCM repository. Currently the +only supported SCM is Git. +The repository would have to the following setup +(which you can checkout here): +. +└── META-INF + └── com.example + └── beer-api-producer-git + └── 0.0.1-SNAPSHOT + ├── contracts + │   └── beer-api-consumer + │   ├── messaging + │   │   ├── shouldSendAcceptedVerification.groovy + │   │   └── shouldSendRejectedVerification.groovy + │   └── rest + │   ├── shouldGrantABeerIfOldEnough.groovy + │   └── shouldRejectABeerIfTooYoung.groovy + └── mappings + └── beer-api-consumer + └── rest + ├── shouldGrantABeerIfOldEnough.json + └── shouldRejectABeerIfTooYoung.json +Under META-INF folder: + + +we group applications via groupId (e.g. com.example) + + +then each application is represented via the artifactId (e.g. beer-api-producer-git) + + +next, the version of the application. The version is mandatory! (e.g. 0.0.1-SNAPSHOT) + + +finally, there are two folders: + + +contracts - the good practice is to store the contracts required by each +consumer in the folder with the consumer name (e.g. beer-api-consumer). That way you +can use the stubs-per-consumer feature. Further directory structure is arbitrary. + + +mappings - in this folder the Maven / Gradle Spring Cloud Contract plugins will push +the stub server mappings. On the consumer side, Stub Runner will scan this folder +to start stub servers with stub definitions. The folder structure will be a copy +of the one created in the contracts subfolder. + + + + +
    +Protocol convention +In order to control the type and location of the source of contracts (whether it’s +a binary storage or an SCM repository), you can use the protocol in the URL of +the repository. Spring Cloud Contract iterates over registered protocol resolvers +and tries to fetch the contracts (via a plugin) or stubs (via Stub Runner). +For the SCM functionality, currently, we support the Git repository. To use it, +in the property, where the repository URL needs to be placed you just have to prefix +the connection URL with git://. Here you can find a couple of examples: +git://file:///foo/bar +git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git +git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git +
    +
    +Producer +For the producer, to use the SCM approach, we can reuse the +same mechanism we use for external contracts. We route Spring Cloud Contract +to use the SCM implementation via the URL that contains +the git:// protocol. + +You have to manually add the pushStubsToScm +goal in Maven or execute (bind) the pushStubsToScm task in +Gradle. We don’t push stubs to origin of your git +repository out of the box. + + +Maven + +<plugin> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-maven-plugin</artifactId> + <version>${spring-cloud-contract.version}</version> + <extensions>true</extensions> + <configuration> + <!-- Base class mappings etc. --> + + <!-- We want to pick contracts from a Git repository --> + <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl> + + <!-- We reuse the contract dependency section to set up the path + to the folder that contains the contract definitions. In our case the + path will be /groupId/artifactId/version/contracts --> + <contractDependency> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + </contractDependency> + + <!-- The contracts mode can't be classpath --> + <contractsMode>REMOTE</contractsMode> + </configuration> + <executions> + <execution> + <phase>package</phase> + <goals> + <!-- By default we will not push the stubs back to SCM, + you have to explicitly add it as a goal --> + <goal>pushStubsToScm</goal> + </goals> + </execution> + </executions> +</plugin> + + + +Gradle + +contracts { + // We want to pick contracts from a Git repository + contractDependency { + stringNotation = "${project.group}:${project.name}:${project.version}" + } + /* + We reuse the contract dependency section to set up the path + to the folder that contains the contract definitions. In our case the + path will be /groupId/artifactId/version/contracts + */ + contractRepository { + repositoryUrl = "git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git" + } + // The mode can't be classpath + contractsMode = "REMOTE" + // Base class mappings etc. +} + +/* +In this scenario we want to publish stubs to SCM whenever +the `publish` task is executed +*/ +publish.dependsOn("publishStubsToScm") + + +With such a setup: + + +Git project will be cloned to a temporary directory + + +The SCM stub downloader will go to META-INF/groupId/artifactId/version/contracts folder +to find contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/contracts + + +Tests will be generated from the contracts + + +Stubs will be created from the contracts + + +Once the tests pass, the stubs will be committed in the cloned repository + + +Finally, a push will be done to that repo’s origin + + +
    +
    +Consumer +On the consumer side when passing the repositoryRoot parameter, +either from the @AutoConfigureStubRunner annotation, the +JUnit rule or properties, it’s enough to pass the URL of the +SCM repository, prefixed with the protocol. For example +@AutoConfigureStubRunner( + stubsMode="REMOTE", + repositoryRoot="git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git", + ids="com.example:bookstore:0.0.1.RELEASE" +) +With such a setup: + + +Git project will be cloned to a temporary directory + + +The SCM stub downloader will go to META-INF/groupId/artifactId/version/ folder +to find stub definitions and contracts. E.g. for com.example:foo:1.0.0 the path would be +META-INF/com.example/foo/1.0.0/ + + +Stub servers will be started and fed with mappings + + +Messaging definitions will be read and used in the messaging tests + + +
    How can I debug the request/response being sent by the generated tests client? @@ -1956,11 +2157,6 @@ matching response definition was picked. to dump all mappings per artifact id. Also the port at which the given stub server was started will be attached.
    -
    -Can I reference the request from the response? -Yes! With version 1.1.0 we’ve added such a possibility. On the HTTP stub server side we’re providing support -for this for WireMock. In case of other HTTP server stubs you’ll have to implement the approach yourself. -
    Can I reference text from file? Yes! With version 1.2.0 we’ve added such a possibility. It’s enough to call file(…​) method in the @@ -2022,6 +2218,9 @@ following sections: + + + @@ -2251,6 +2450,10 @@ 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 +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: @@ -2336,6 +2539,19 @@ generated from src/test/resources/contract/com/ contracts ext To ensure that the provider side is compliant with defined contracts, you need to invoke: ./gradlew generateContractTests test
    +
    +Pushing stubs to SCM +If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to call the pushStubsToScm +task. Example: +$ ./gradlew pushStubsToScm +Under you can find all possible +configuration options that you can pass either via +the contractsProperties field e.g. contracts { contractsProperties = [foo:"bar"] }, +via contractsProperties method e.g. contracts { contractsProperties([foo:"bar"]) }, +a system property or an environment variable. +
    Spring Cloud Contract Verifier on the Consumer Side In a consuming service, you need to configure the Spring Cloud Contract Verifier plugin @@ -2408,6 +2624,9 @@ following sections: + + + @@ -2646,6 +2865,10 @@ the matched contract. For example, if you have a contract under extends com.example.base.BaseClass. This setting takes precedence over packageWithBaseClasses and baseClassForTests. + +contractsProperties: a map containing properties to be passed to Spring Cloud Contract +components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders. + If you want to download your contract definitions from a Maven repository, you can use the following options: @@ -2841,13 +3064,58 @@ goal. To ensure that provider side is compliant with defined contracts, you need to invoke mvn generateTest test.
    +
    +Pushing stubs to SCM +If you’re using the SCM repository to keep the contracts and +stubs, you might want to automate the step of pushing stubs to +the repository. To do that, it’s enough to add the pushStubsToScm +goal. Example: +<plugin> + <groupId>org.springframework.cloud</groupId> + <artifactId>spring-cloud-contract-maven-plugin</artifactId> + <version>${spring-cloud-contract.version}</version> + <extensions>true</extensions> + <configuration> + <!-- Base class mappings etc. --> + + <!-- We want to pick contracts from a Git repository --> + <contractsRepositoryUrl>git://https://github.com/spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl> + + <!-- We reuse the contract dependency section to set up the path + to the folder that contains the contract definitions. In our case the + path will be /groupId/artifactId/version/contracts --> + <contractDependency> + <groupId>${project.groupId}</groupId> + <artifactId>${project.artifactId}</artifactId> + <version>${project.version}</version> + </contractDependency> + + <!-- The contracts mode can't be classpath --> + <contractsMode>REMOTE</contractsMode> + </configuration> + <executions> + <execution> + <phase>package</phase> + <goals> + <!-- By default we will not push the stubs back to SCM, + you have to explicitly add it as a goal --> + <goal>pushStubsToScm</goal> + </goals> + </execution> + </executions> +</plugin> +Under you can find all possible +configuration options that you can pass either via +the <configuration><contractProperties> map, a system property +or an environment variable. +
    Maven Plugin and STS If you see the following exception while using STS: - + STS Exception @@ -8608,6 +8876,67 @@ If you provide the stubsMode = StubRunnerProperties.StubsMode.LOCAL
    +
    +Using the SCM Stub Downloader +Whenever the repositoryRoot starts with a SCM protocol +(currently we support only git://), the stub downloader will try +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 + +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) +* STUBRUNNER_PROPERTIES_GIT_USERNAME (env prop) + +Git clone username + + +* git.password (plugin prop) +* stubrunner.properties.git.password (system prop) +* STUBRUNNER_PROPERTIES_GIT_PASSWORD (env prop) + +Git clone password + + +* git.no-of-attempts (plugin prop) +* stubrunner.properties.git.no-of-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_NO_OF_ATTEMPTS (env prop) +10 +Number of attempts to push the commits to origin + + +* git.wait-between-attempts (Plugin prop) +* stubrunner.properties.git.wait-between-attempts (system prop) +* STUBRUNNER_PROPERTIES_GIT_WAIT_BETWEEN_ATTEMPTS (env prop) +1000 +Number of millis to wait between attempts to push the commits to origin + + + +
    +
    Spring Cloud Contract WireMock @@ -9012,6 +9341,10 @@ contract. The location of this file would be index/dsl-contract.adoc Migrations + +For up to date migration guides please visit +the project’s wiki page. + This section covers migrating from one version of Spring Cloud Contract Verifier to the next version. It covers the following versions upgrade paths: