without this people can be surprised with the transitive dependencies being included in their project from stub jars.
We explain 3 different approaches to solving this issue.
Fixes#55
* reorganized the entries (now the Contract details went to the very bottom)
* added FAQ section where versioning and dynamic props are better defined
* added in a couple of places links to Groovy JSON docs
fixes#69
TODO: currently to make things work I had to pass ribbon.eureka.enabled=false, I'll have to think if I can somehow override it. The problem is that I have a lot of stuff on the classpath...
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
What we're missing ATM is different documentation versions for different application versions. What this change does is that it's:
- finding out what is the current branch (e.g. 1.0.x)
- finding out out what is the name of the main adoc file (e.g. spring-cloud-sleuth)
- pulling the changes from gh-pages after checkout
- finding out what is the list of comma separated whitelisted branches (via the `docs.whitelisted.branches` prop)
- in gh-pages creating a folder with name of the branch (e.g. /1.0.x)
copying all the docs/target/generated-docs/ to that folder
- if the branch from which we're calling the script is NOT master then we're changing the ${main.adoc}.html to index.html so that it's easier to access the docs (e.g. http://cloud.spring.io/spring-cloud-sleuth/1.0.x/)
