Replaced custom caching of the downloaded contracts with Gradle's
incremental build. After that `InitContractsTask` is not needed any
more, as its main purpose was to be a bridge between custom caching
and Gradle's one. Simplified code to download contracts is now part of
the `ContractsCopyTask`.
Also fixed `PublishStubsToScmTask` and removed incremental stuff from
there for now.
Fixes gh-1133
With current implementation of the `GradleContractsDownloader`, where
we have custom caching, `InitContractsTask` doesn't really need to be
incremental. Moreover, there is an issue in current implementation of
the `InitContractsTask`: it doesn't mark itself as out of date when
dynamic dependency is used (`+` or `SNAPSHOT` version). So for now just
disabling incremental build for that task.
Also restored old behaviour, where we used to always use `".*"` pattern
to define included contracts for `GenerateServerTests` task.
Also fixed minor logging issue.
Fixes gh-1133
In order to make it working - I had to define clear input and output
params for each gradle task.
As part of this task I've also cleaned up some services to define clear
inputs instead of generic `ContractVerifierConfigProperties`.
Fixes gh-1133
* Add a switch to fail on no stubs
without this change we throw an exception if no stubs / contracts were found
with this change we catch exceptions from aether stub downloader and if there are no stubs found whatsover, and a switch is set to fail in that case, then we do throw an exception that no stubs / contracts were found
fixes gh-895
* Generate stubs at runtime
without this change the producer side must publish the stubs for the consumer side to use them
with this change the consumer can toggle a switch so that the stubs get generated at runtime. This might of course lead to false positivies but we assume that the users know what they're doing
fixes gh-881
* Rewritting to java
- rewritten a lot of Spring Cloud Contract Spec module to Java
- extracted all Groovy stuff to a separate package
- will now continue writing extension modules
- spring-cloud-contract-spec will be written purely in java
- spring-cloud-contract-spec-groovy will have Groovy extensions
fixes gh-1130
following two event storming sessions with @pilloPl and @OlgaMaciaszek and the Spring Cloud Contract community we've decided to refactor the core modules of Spring Cloud Contract Verifier.
The main idea is that the current `JavaTestGenerator`'s implementation no longer uses complex logic to generate classes and methods.
We've introduced abstractions such as:
- class body builder (to build classes)
- groovy and java class metadata
- imports (for various frameworks)
- default setup for json, xml, restassured, jaxrs
- class annotations for spock, junit and junit5
- field insertion e.g. for messaging
