without this change when using a daemon, for snapshot versions of downloaded contracts allways the same folder is returned
with this change we cache only non snapshot artifacts; also there's a switch you can set to disable caching at all
fixes#343
That way we do not interfere with whatever Maven brings on its classpath
without this change deployment might fail due to being unauthorized.
with this change we're shading aether and maven in stub runner. Due to this there is no classpath clash any more
fixes#325
without this change even though we want a remote repo to be used for the artifact we return a cached instance
with this change we're throwing an exception if we can't download the artifact and we found one cached in the local repo
fixes#312
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
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
The best situation is to provide fixed values but sometimes you need to reference a request in your response. In order to do this you can profit from the fromRequest() method that allows you to reference a bunch of elements from the HTTP request. You can use the following options:
- `fromRequest().url()` - return the request URL
- `fromRequest().query(String key)` - return the first query parameter with a given name
- `fromRequest().query(String key, int index)` - return the nth query parameter with a given name
- `fromRequest().header(String key)` - return the first header with a given name
- `fromRequest().header(String key, int index)` - return the nth header with a given name
- `fromRequest().body()` - return the full request body
- `fromRequest().body(String jsonPath)` - return the element from the request that matches the JSON Path
fixes#237
without this change the local repository maven setup is completely ignored
with this change whatever you have set up locally will be taken into consideration
