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
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
* 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
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/)
