without this change we always set the default value of the package with generated tests, unless a value overrides it.
with this change the flow for setting the generated tests package name will look like this:
- pick basePackageForTests
- if basePackageForTests wasn't set pick the package from baseClassForTests
- if baseClassForTests wasn't set pick packageWithBaseClasses
- if nothing got set pick the default org.springframework.cloud.contract.verifier.tests
The rationale behind this change is such that often in the base class you would like to have package scoped methods and the fact that the tests are always generated in the default location requires to make these methods public or always override this property.
fixes#260
without this change there's no way to change the default path of the path to the contracts when trying to execute the convert / generateTests task for another project
with this change we're setting properly the `spring.cloud.contract.verifier.contractsDirectory` for both tasks
fixes#338
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 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 the stubs are just placed under the contracts|mappings folders. If you have many of these JARs on the classpath then you might have a problem to say which stubs belong to which server.
with this change we're changing the default location to META-INF/groupid/artifactid/version/contract|mappings . That way you can easily discern stubs
fixes#54
we're hiding the details related to assertions in our new abstraction over assertj assertions. That way we'll be able to add new methods in an easy way. There will be no need to create annonymous conditions etc.
with this change we're providing support for Pact based contracts. No longer do you have to set up your contracts using the Groovy DSL. In the same way as with the DSL you can use the Pact contracts to generate tests and the stubs on the producer side.
fixes#96
