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
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
* 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 feature we're missing an option to print all mappings registered for servers
with this feature it will be much easier to debug what was registered in which http server stub. The mappings will be dumped to files with name artifactName_registeredPort
fixes#355
without this change we're very strict in terms of the number of called send methods on the rabbittemplate
with this change we accept that the method could have been called more than once
fixes#332
without this change not only can't you configure messaging for JUnit rule but also the default option is misleading - it fials to send any messages and returns true
with this change we're allowing configuration options and change the default behaviour to throwing unsupported operation exceptions
fixes#280
