This section covers migrating from one version of Spring Cloud Contract Verifier to the +
![[Tip]](images/tip.png) | 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:
This section covers upgrading from version 1.0 to version 1.1.
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 @@
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:
- 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
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
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.Let’s assume that we have a producer with coordinates
com.example:serverand 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
propertycontractsDslDircontracts { - +build.dependsOn("deleteUnwantedContracts")
- Configure plugin by specifying the directory containing contracts using
contractsDslDirpropertycontracts { contractsDslDir = new File("${buildDir}/unpackedContracts") -}
Yes! Check out the Different base classes for contracts sections -of either Gradle or Maven plugins.
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=DEBUGIn 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 thestubs-per-consumerfeature. 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 thecontractssubfolder.
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
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]](images/important.png) | Important |
|---|---|
You have to manually add the |
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/contractsfolder +to find contracts. E.g. forcom.example:foo:1.0.0the 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
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. forcom.example:foo:1.0.0the 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
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=DEBUGStarting 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=ERRORYou 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.
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.
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.
Assume that we have a system consisting of multiple microservices:
If we wanted to test the application in top left corner to determine whether it can +Spring Cloud Contract Verifier.
Assume that we have a system consisting of multiple microservices:
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.
Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.
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.
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
@@ -393,8 +393,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-idofhttp-server, while Loan Issuance has an artifact-id ofhttp-client, and both have agroup-idofcom.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 In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.
If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:
Maven. diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html index d0d3becf8d..e616c64a16 100644 --- a/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/multi/multi__spring_cloud_contract_verifier_setup.html @@ -1,7 +1,7 @@
4. Spring Cloud Contract Verifier Setup You can set up Spring Cloud Contract Verifier in the following ways:
To learn how to set up the Gradle project for Spring Cloud Contract Verifier, read the -following sections:
- Section 4.1.1, “Prerequisites”
- Section 4.1.2, “Add Gradle Plugin with Dependencies”
- Section 4.1.3, “Gradle and Rest Assured 2.0”
- Section 4.1.4, “Snapshot Versions for Gradle”
- Section 4.1.5, “Add stubs”
- Section 4.1.7, “Default Setup”
- Section 4.1.8, “Configure Plugin”
- Section 4.1.9, “Configuration Options”
- Section 4.1.10, “Single Base Class for All Tests”
- Section 4.1.11, “Different Base Classes for Contracts”
- Section 4.1.12, “Invoking Generated Tests”
- Section 4.1.13, “Spring Cloud Contract Verifier on the Consumer Side”
In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a +following sections:
- Section 4.1.1, “Prerequisites”
- Section 4.1.2, “Add Gradle Plugin with Dependencies”
- Section 4.1.3, “Gradle and Rest Assured 2.0”
- Section 4.1.4, “Snapshot Versions for Gradle”
- Section 4.1.5, “Add stubs”
- Section 4.1.7, “Default Setup”
- Section 4.1.8, “Configure Plugin”
- Section 4.1.9, “Configuration Options”
- Section 4.1.10, “Single Base Class for All Tests”
- Section 4.1.11, “Different Base Classes for Contracts”
- Section 4.1.12, “Invoking Generated Tests”
- Section 4.1.13, “Pushing stubs to SCM”
- Section 4.1.14, “Spring Cloud Contract Verifier on the Consumer Side”
In order to use Spring Cloud Contract Verifier with WireMock, you muse use either a Gradle or a Maven plugin.
![[Warning]](images/warning.png)
Warning If you want to use Spock in your projects, you must add separately the
spock-coreandspock-springmodules. Check Spock docs for more informationTo add a Gradle plugin with dependencies, use code similar to this:
buildscript { @@ -133,7 +133,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:classifiercoordinates. You can use thecontractDependency@@ -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 thepackageWithBaseClassesas a fallback.) That way, the tests generated fromsrc/test/resources/contract/com/contracts extend the -com.example.ComBase, whereas the rest of the tests extendcom.example.FooBase.To ensure that the provider side is compliant with defined contracts, you need to invoke:
./gradlew generateContractTests testIn a consuming service, you need to configure the Spring Cloud Contract Verifier plugin +
com.example.ComBase, whereas the rest of the tests extendcom.example.FooBase.To ensure that the provider side is compliant with defined contracts, you need to invoke:
./gradlew generateContractTests testIf 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
contractsPropertiesfield e.g.contracts { contractsProperties = [foo:"bar"] }, +viacontractsPropertiesmethod e.g.contracts { contractsProperties([foo:"bar"]) }, +a system property or an environment variable.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/contractsand generate WireMock JSON stubs using:./gradlew generateClientStubs
![[Note]](images/note.png)
Note The
stubsOutputDiroption 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 } }
LoanApplicationmakes a call toFraudDetectionservice. This request is handled by a WireMock server configured with stubs generated by Spring Cloud Contract Verifier.\ No newline at end of file +If you provide more than one, then the first one on the list is used.To learn how to set up the Maven project for Spring Cloud Contract Verifier, read the -following sections:
- Section 4.2.1, “Add maven plugin”
- Section 4.2.2, “Maven and Rest Assured 2.0”
- Section 4.2.3, “Snapshot versions for Maven”
- Section 4.2.4, “Add stubs”
- Section 4.2.5, “Run plugin”
- Section 4.2.6, “Configure plugin”
- Section 4.2.7, “Configuration Options”
- Section 4.2.8, “Single Base Class for All Tests”
- Section 4.2.9, “Different base classes for contracts”
- Section 4.2.10, “Invoking generated tests”
- Section 4.2.11, “Maven Plugin and STS”
Add the Spring Cloud Contract BOM in a fashion similar to this:
<dependencyManagement> +following sections:
- Section 4.2.1, “Add maven plugin”
- Section 4.2.2, “Maven and Rest Assured 2.0”
- Section 4.2.3, “Snapshot versions for Maven”
- Section 4.2.4, “Add stubs”
- Section 4.2.5, “Run plugin”
- Section 4.2.6, “Configure plugin”
- Section 4.2.7, “Configuration Options”
- Section 4.2.8, “Single Base Class for All Tests”
- Section 4.2.9, “Different base classes for contracts”
- Section 4.2.10, “Invoking generated tests”
- Section 4.2.11, “Pushing stubs to SCM”
- Section 4.2.12, “Maven Plugin and STS”
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 extendscom.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/artifactidwheregropuidis slash separated. - contractsMode: Picks the mode in which stubs will be found and registered
- contractsSnapshotCheckSkip: If
truethen will not assert whether a stub / contract JAR was downloaded from local or remote location - deleteStubsAfterTest: If set to
falsewill 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.
If you see the following exception while using STS:
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.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.If you see the following exception while using STS:
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 If you do not provide any implementation, then the default is used (scan classpath). If you provide the
stubsMode = StubRunnerProperties.StubsMode.LOCALor, stubsMode = StubRunnerProperties.StubsMode.REMOTEthen the Aether implementation will be used -If you provide more than one, then the first one on the list is used.
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 |
* | master | Which branch to checkout |
* | Git clone username | |
* | Git clone password | |
* | 10 | Number of attempts to push the commits to |
* | 1000 | Number of millis to wait between attempts to push the commits to |
_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