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
without this change when we work with the repo with common contracts then in the logs we can see that a lot of unnecessary files are processed. Those files are related to the fact that `target` / `build` folders are created and reside in the path in which we're searching for contracts. Due to this we have duplicates in terms of converting files.
with this change we add the `excludeBuildFolders` property that is by default turned off. If you enable it in the `pom.xml` that is used by the consumers to install stubs locally then the target folder gets ignored.
fixes#167
the biggest problem was related with the scenario in which a jar with shared contracts is downloaded
with this change the output JAR structure is proper
fixes#156
When using contract plugins together with a shared repo with contracts we end up with creating contract tests for all the contracts. Stubs are created properly but tests generation ignores the path pattern.
With this change we fix the way tests are generated
fixes#155
without this change you can't control what should be excluded from your folder in the output stubs jar. That way when having a common repo with contracts you had the whole target put into stubs jar
with this change you can set e.g. `**/target/**/*.*` to exclude anything from the target folder
fixes#145
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
