without this it can be misunderstood that execute() can be used with Strings
with this we're informing the users that the value of the given property (url, header, body) has to be uniquely a execute command
fixes#231
without this change it's impossible to assert with response matchers all elements of an array
with this change we're using AssertJs conditions in case the pattern contains [*]
fixes#217
Without this change we're forcing users to embed their dynamic properties inside the body. For some this is natural and acceptable, but especially for the users coming from the Pact world this sounds bizarre. Also some other people have a problem with remembering who the consumer / producer is etc.
With this change we're introducing the stubMatchers and testMatchers section. Thanks to this one can separate the body from defining the dynamic properties. Especially for Pact users this is more natural. Speaking of which this is a prerequisite for #96fixes#185
without this change the explicit mode is broken and context path scenario can't be tested
with this change you can provide the EXPLICIT mode with which you can set the RestAssured to send real requests. That way you can set up your application to listen on a socket and have the context path setup. The contracts need to include the context path too since in real world you'll send a request to a URL that contains a context path element.
fixes#179#117
without this change if someone used the Spring Cloud BOM one could have some dependency related issues coming from exclusions of WireMock dependencies in SPring CLoud COntract
with this change we're informing the user about this
fixes#146
without this change only explicit Spring AMQP support was present
with this change support for spring-amqp annotated listener endpoints was added
fixes#127
without this change when the user adds context-path it gets ignored and WireMock fails to register stubs
with this change we update the WireMock instance to include the context path
fixes#99
without this change the only way to ignore a contract was to provide it in the plugin's config
with this change you can also set it on the contract itself.
fixes#30
without this change the user was forced to use a single base class for all of the generated tests. It could become problematic after some time.
With this change we provide a range of options of providing different base classes for different contracts.
fixes#16
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
