diff --git a/multi/multi__spring_cloud_contract_verifier_setup.html b/multi/multi__spring_cloud_contract_verifier_setup.html index da38d9dc95..52e96eb960 100644 --- a/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/multi/multi__spring_cloud_contract_verifier_setup.html @@ -575,7 +575,52 @@ or an environment variable.
The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One +</build>
You can select the Spock Framework for creating and executing the auto-generated contract +verification tests with both Maven and Gradle plugin. However, whereas with Gradle its really straightforward, +in Maven you will require some additional setup in order to make the tests compile and execute properly.
First of all, you will have to use a plugin, such as GMavenPlus plugin, +to add Groovy to your project. In GMavenPlus plugin, you will need to explicitly set test sources, including both the +path where your base test classes are defined and the path were the generated contract tests are added. +Please refer to the example below:
<plugin> + <groupId>org.codehaus.gmavenplus</groupId> + <artifactId>gmavenplus-plugin</artifactId> + <version>1.6.1</version> + <executions> + <execution> + <goals> + <goal>compileTests</goal> + <goal>addTestSources</goal> + </goals> + </execution> + </executions> + <configuration> + <testSources> + <testSource> + <directory>${project.basedir}/src/test/groovy</directory> + <includes> + <include>**/*.groovy</include> + </includes> + </testSource> + <testSource> + <directory> + ${project.basedir}/target/generated-test-sources/contracts/com/example/beer + </directory> + <includes> + <include>**/*.groovy</include> + <include>**/*.gvy</include> + </includes> + </testSource> + </testSources> + </configuration> + <dependencies> + <dependency> + <groupId>org.codehaus.groovy</groupId> + <artifactId>groovy-all</artifactId> + <version>2.4.15</version> + <scope>runtime</scope> + <type>pom</type> + </dependency> + </dependencies>
If you uphold to the Spock convention of ending the test class names with Spec, you will also need to adjust your Maven
+Surefire plugin setup, like in the following example:
The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One problem that arises is that, when reusing the stubs, you can mistakenly import all of that stub’s dependencies. When building a Maven artifact, even though you have a couple of different jars, all of them share one pom:
├── github-webhook-0.0.1.BUILD-20160903.075506-1-stubs.jar diff --git a/multi/multi__using_the_pluggable_architecture.html b/multi/multi__using_the_pluggable_architecture.html index 36bc274fcf..d67d70cfe4 100644 --- a/multi/multi__using_the_pluggable_architecture.html +++ b/multi/multi__using_the_pluggable_architecture.html @@ -421,7 +421,7 @@ to clone the repository and use it as a source of contracts to generate tests or stubs.Either via environment variables, system properties, properties set inside the plugin or contracts repository configuration you can tweak the downloader’s behaviour. Below you can find the list of -properties
Table 10.1. SCM Stub Downloader properties