When fetching stubs / contracts in a CI, shared environment, what might happen is that
both the producer and the consumer reuse the same local Maven repository. Due to this,
the framework, responsible for downloading a stub JAR from remote location,
can't decide which JAR should be picked, local or remote one. That caused
the `"The artifact was found in the local repository but you have explicitly
stated that it should be downloaded from a remote one"` exception
and failed the build.
For such cases we're introducing the property mechanism:
- via `stubrunner.snapshot-check.skip` system property
- via `STUBRUNNER_SNAPSHOT_CHECK_SKIP` environment variable
if either of these values is set to `true`, then the stub downloader will not
verify the origin of the downloaded JAR.
fixes gh-545
The correct WireMock JSON stubs should be available after this change.
Otherwise the json paths that were applied to the request in the
RESTdocs test were being translated into response matchers in the
contract (which doesn't even do anything in WireMock).
with this change we're adding generation of 2 docker images - verifier and stub runner
we also added a project `spring-cloud-contract-stub-runner-boot` which contains a far jar with stub runner boot
fixes gh-526, gh-516
without this change we're escaping the json body response and then wiremock is escaping it again
with this change we're unescaping the first json body escaping so that wiremock applies it only once
fixes gh-515
without this change we're using Eureka lite to register the apps. However we're not reusing any mechanisms that are bound to registration of the main app. That's why we also loose the OAuth2 instrumentation of Spring Cloud Services.
with this change we're reusing the default mechanism. For Cloud based applications we also register the stubs under a different route so as to support the multiple port binding.
fixes gh-490
