with this change we're providing support for Pact based contracts. No longer do you have to set up your contracts using the Groovy DSL. In the same way as with the DSL you can use the Pact contracts to generate tests and the stubs on the producer side.
fixes#96
The problem is that it is a Spring Boot app (really tiny one), so
it binds to server.* in the environment, if you try to use
the stock ServerProperties. We only need a subset of the features
so it's actually relatively easy to wrap it and use a delegate.
With this functionality you can have one centralized repository containing all contracts. This repo will have to produce a JAR containing all contracts. The layout of the repository can be arbitrary but some sensible defaults are assumed. The producer will be able to then download that JAR and produce tests and stubs from it.
fixes#38
before this change the support for Stub Runner Boot with Service Discovery was pretty useless since Stub Runner stubbed service discovery. That makes a lot of sense in unit / integration tests but not when you want to do some version of end to end tests.
With this change you can pass a property to enable automated registration of stubs in Service Discovery.
Technical changes:
* Added Zookeeper registration
* Added Eureka registration
* Added Consul registration
* Added checkstyle plugin - fixed part of exceptions
* Added options to pass props via @AutoConfigureStubRunner
it's much easier to pass props via the annotation instead of property files. With this change the user can provide the properties inside the test via the annotation. The only thing that has to be passed via props is repositoryRoot (typically it's a very constant property that you set once).
fixes#46
without this change if you want to use Spring Cloud Contract Stub Runner Cloud you need to have an implementation of Service Discovery on your classpath. That's not always what you want to have - actually the tests should be possible to be run without any backing service disvoery technology.
This change provides the default NoOp Discovery Client in case where there is no bean of DiscoveryClient type.
fixes#56
there was a problem with the way property related to array size check was passed. Not only was the condition inverse, but also the properties weren't passed.
With this change those issues were fixed, we've added the missing maven plugin feature and ensured that the array check is the default option.
fixes#60
