with this change there are numerous helper methods that should provide a more descriptive DSL for the response status. Instead of a numerical status you can now call a method e.g. instead of 200 call OK()
fixes gh-575
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
* Introduces explicit mode of stub downloading
you have to explicitly provide the mode [CLASSPATH, REMOTE, LOCAL] of how you want to fetch and register stubs
fixes gh-287
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
without this change we're completely ignoring the option of using system properties to set the stub runner builder options
with this change we set it up with defaults from system properties and then we override it with the user's code
fixes#462
without this change we set only a single extension "response-transformer" without an option to provide any other ones
with this change we introduce the "spring.factories" based extension model. It's enough to provide your own implementation of `org.springframework.cloud.contract.verifier.dsl.wiremock.WireMockExtensions` and register it in `spring.factories`. That way you can control all extensions (request / response).
fixes#425