With such a setup:
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/contractsoriginOn the consumer side when passing the repositoryRoot parameter,
+META-INF/com.example/foo/1.0.0/contracts
originIt is also possible to keep the contracts in the producer repository, but keep the stubs in an external git repo. +This is most useful when you want to use the base consumer-producer collaboration flow, but do not have a possibility to +use an artifact repository for storing the stubs.
In order to do that, use the usual producer setup, and then add the pushStubsToScm goal and set
+contractsRepositoryUrl to the repository where you want to keep the stubs.
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( diff --git a/2.0.x/multi/multi__using_the_pluggable_architecture.html b/2.0.x/multi/multi__using_the_pluggable_architecture.html index d0ea23586a..fcceb4079b 100644 --- a/2.0.x/multi/multi__using_the_pluggable_architecture.html +++ b/2.0.x/multi/multi__using_the_pluggable_architecture.html @@ -422,7 +422,7 @@ to clone the repository and use it as a source of contracts to generate tests or stubs.Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties
Table 10.1. SCM Stub Downloader properties