without this change you can by mistake use the http headers in a messaging headers which will fail to work
with this change we're adding the messagingContentType() method that allows to properly set the content type
fixes#296
With contract like this
```
// output message of the contract
outputMessage {
// destination to which the output message will be sent
sentTo 'verifications'
// the body of the output message
body(
eligible: true
)
headers {
header("contentType", applicationJsonUtf8())
}
}
```
the generated test produces
```
ContractVerifierMessage response = contractVerifierMessaging.receive("verifications");
assertThat(response.getHeader("contentType")).isEqualTo("application/json;charset=UTF-8");
```
The headers in the response is a MimeType not a String so the equality check fails.
fixes#297
There are cases in which 2 consumers of the same endpoint want to have 2 different responses. Without this change we don't support it. We don't support that consumers may overlap with their contracts. The outcome of such overlapping is that the first matching stub will be registered in HTTP server stub and the other will be ignored.
With this change we're allowing such a thing to happen. Each consumer can set the `stubrunner.stubs-per-consumer` flag and the `spring.application.name` or `stubrunner.consumer-name` flag will be taken into consideration. If the consumer's name is present in the path of a stub / contract then its mapping / messaging contract will be reused in tests. If not then it will get ignored
fixes#224
wiuthout this change Intellij support wasn't great if one hasn't applied the idea plugin
with this change if someone's using Intellij (we check that by verifying the presence of .idea folder) then we apply the plugin automatically
fixes#286
with the new layout of contracts and stubs the package name was improperly generated (for chars like +, or digits)
with this change we're converting those chars to _
fixes#276
without this change there's no option to use Stub Runner to pick stubs from classpath
with this change we're adding that option. It's enough for the user not to provide neither the `repositoryRoot` nor `workOffline`. If that's the case then Classpath scanning will take place.
fixes#282
without this change we're forcing the users to turn on web components even they don't use them
with this change if there are no mappings or contracts then we do not start the web server
fixes#279
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
