comment out many includes for release.
Some probably didn't need to be, but I just did it until Unresolved is gone
This commit is contained in:
spencergibb
@@ -479,7 +479,9 @@ include::{contract_kotlin_spec_path}/src/test/kotlin/org/springframework/cloud/c
|
||||
|
||||
In the following sections you can find examples of the supported metadata entries.
|
||||
|
||||
////
|
||||
include::{project-root}/docs/target/metadata.adoc[indent=0]
|
||||
////
|
||||
|
||||
[[features-http]]
|
||||
== Contracts for HTTP
|
||||
|
||||
@@ -16,6 +16,7 @@ You can add the additional snapshot repository to your build file to use snapsho
|
||||
versions, which are automatically uploaded after every successful build, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Maven
|
||||
----
|
||||
@@ -27,6 +28,7 @@ include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0]
|
||||
----
|
||||
include::{standalone_samples_path}/http-server/build.gradle[tags=repos,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[features-stub-runner-publishing-stubs-as-jars]]
|
||||
@@ -41,6 +43,7 @@ it if you want to.
|
||||
The following example shows how to publish stubs as jars:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Maven
|
||||
----
|
||||
@@ -53,12 +56,15 @@ include::{samples_url}/producer_with_restdocs/pom.xml[tags=assembly,indent=0]
|
||||
<!-- Finally setup your assembly. Below you can find the contents of src/main/assembly/stub.xml -->
|
||||
include::{samples_url}/producer_with_restdocs/src/assembly/stub.xml[indent=0]
|
||||
----
|
||||
////
|
||||
|
||||
////
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="secondary"]
|
||||
.Gradle
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/scenarioProject/build.gradle[tags=jar_setup,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[features-stub-runner-core]]
|
||||
@@ -244,19 +250,23 @@ example shows how to do so:
|
||||
|
||||
.WireMockHttpServerStubConfigurer implementation
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=wireMockHttpServerStubConfigurer]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
You can then reuse it with the `@AutoConfigureStubRunner` annotation, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=annotation]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Whenever an HTTPS port is found, it takes precedence over the HTTP port.
|
||||
@@ -372,10 +382,12 @@ Stub Runner comes with a JUnit rule that lets you can download and run stubs for
|
||||
group and artifact ID, as the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleJUnitTest.java[tags=classrule]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
A `StubRunnerExtension` is also available for JUnit 5. `StubRunnerRule` and
|
||||
@@ -398,15 +410,18 @@ Since the `StubRunnerRule` and `StubRunnerExtension` implement the `StubFinder`,
|
||||
you find the started stubs, as the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/main/java/org/springframework/cloud/contract/stubrunner/StubFinder.java[lines=16..-1]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
The following examples provide more detail about using Stub Runner:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Spock
|
||||
----
|
||||
@@ -424,6 +439,7 @@ include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contra
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/java/org/springframework/cloud/contract/stubrunner/junit/StubRunnerJUnit5ExtensionTests.java[tags=extension]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
See the <<features-stub-runner-common-properties-junit-spring>> for more information on
|
||||
@@ -454,19 +470,23 @@ When using the `StubRunnerRule` or `StubRunnerExtension`, you can add a stub to
|
||||
and then pass the port for the last downloaded stub. The following example shows how to do so:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleCustomPortJUnitTest.java[tags=classrule_with_port]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
For the preceding example, the following test is valid:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/junit4/StubRunnerRuleCustomPortJUnitTest.java[tags=test_with_port]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[features-stub-runner-rule-spring]]
|
||||
@@ -481,29 +501,35 @@ If you want to find the URL of your stubbed dependency, you can autowire the `St
|
||||
its methods, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/StubRunnerConfigurationSpec.groovy[tags=test]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Doing so depends on the following configuration file:
|
||||
|
||||
====
|
||||
////
|
||||
[source,yml,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/resources/application-test.yml[tags=test]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Instead of using the properties, you can also use the properties inside the `@AutoConfigureStubRunner`.
|
||||
The following example achieves the same result by setting values on the annotation:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerSpringCloudAutoConfigurationSpec.groovy[tags=autoconfigure]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Stub Runner Spring registers environment variables in the following manner
|
||||
@@ -559,19 +585,23 @@ instead of calling the real Service Discovery tool.
|
||||
For example, the following test passes:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerSpringCloudAutoConfigurationSpec.groovy[tags=test]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Note that the preceding example requires the following configuration file:
|
||||
|
||||
====
|
||||
////
|
||||
[source,yml,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/resources/application.yml[tags=ids]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[features-stub-runner-cloud-stubbing-profiles]]
|
||||
@@ -709,10 +739,12 @@ For Messaging, Stub Runner Boot makes the following endpoints available:
|
||||
|
||||
The following example shows typical usage of Stub Runner Boot:
|
||||
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/server/StubRunnerBootSpec.groovy[tags=boot_usage]
|
||||
----
|
||||
////
|
||||
|
||||
[[features-stub-runner-boot-service-discovery]]
|
||||
==== Stub Runner Boot with Service Discovery
|
||||
@@ -731,10 +763,12 @@ required stubs and registering them in a service discovery tool. Consider the fo
|
||||
such a setup with Eureka (assume that Eureka is already running):
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/serverexamples/StubRunnerBootEurekaExample.java[tags=stubrunnereureka]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
We want to start a Stub Runner Boot server (`@EnableStubRunnerServer`), enable the Eureka client (`@EnableEurekaClient`),
|
||||
@@ -745,10 +779,12 @@ We can do so by running the application with `java -jar ${SYSTEM_PROPS} stub-run
|
||||
`${SYSTEM_PROPS}` contains the following list of properties:
|
||||
|
||||
====
|
||||
////
|
||||
[source,bash,indent=0]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/serverexamples/StubRunnerBootEurekaExample.java[tags=stubrunnereureka_args]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
That way, your deployed application can send requests to started WireMock servers through service
|
||||
@@ -826,12 +862,14 @@ The `bar-consumer` consumer can either set the `spring.application.name` or the
|
||||
Alternatively, you can set the test as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerSpec.groovy[tags=test]
|
||||
...
|
||||
}
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Then only the stubs registered under a path that contains `bar-consumer` in its name (that is, those from the
|
||||
@@ -840,12 +878,14 @@ Then only the stubs registered under a path that contains `bar-consumer` in its
|
||||
You can also set the consumer name explicitly, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy]
|
||||
----
|
||||
include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contract/stubrunner/spring/cloud/StubRunnerStubsPerConsumerWithConsumerNameSpec.groovy[tags=test]
|
||||
...
|
||||
}
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Then only the stubs registered under a path that contains the `foo-consumer` in its name (that is, those from the
|
||||
|
||||
@@ -117,17 +117,21 @@ the `PUT` method. The following listing shows a contract to check whether a clie
|
||||
be marked as a fraud in both Groovy and YAML:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0,role="primary"]
|
||||
.groovy
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
|
||||
----
|
||||
////
|
||||
|
||||
////
|
||||
[source,yaml,indent=0,role="secondary"]
|
||||
.yaml
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[getting-started-three-second-tour]]
|
||||
@@ -173,10 +177,12 @@ Then you can add the Spring Cloud Contract Verifier dependency and plugin to you
|
||||
the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
The following listing shows how to add the plugin, which should go in the build/plugins
|
||||
@@ -249,10 +255,12 @@ To do so, add the dependency to `Spring Cloud Contract Stub Runner`, as the
|
||||
following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
You can get the Producer-side stubs installed in your Maven repository in either of two
|
||||
@@ -277,10 +285,12 @@ pass the stub artifact IDs and artifact repository URL as `Spring Cloud Contract
|
||||
Stub Runner` properties, as the following example shows:
|
||||
+
|
||||
====
|
||||
////
|
||||
[source,yaml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation,
|
||||
@@ -330,10 +340,12 @@ To start working with `Spring Cloud Contract`, you can add the Spring Cloud Cont
|
||||
dependency and plugin to your build file, as the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
The following listing shows how to add the plugin, which should go in the build/plugins
|
||||
@@ -745,10 +757,12 @@ WireMock instance or messaging route that simulates the actual service.
|
||||
To get started, add the dependency to `Spring Cloud Contract Stub Runner`, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
You can get the Producer-side stubs installed in your Maven repository in either of two
|
||||
@@ -772,10 +786,12 @@ pass the stub artifact IDs and artifact repository URL as `Spring Cloud Contract
|
||||
Runner` properties, as the following example shows:
|
||||
+
|
||||
====
|
||||
////
|
||||
[source,yaml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation,
|
||||
@@ -852,17 +868,21 @@ If you use the SNAPSHOT, Milestone, or Release Candidate versions, you need to a
|
||||
following section to your build:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Maven
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=repos,indent=0]
|
||||
----
|
||||
////
|
||||
|
||||
////
|
||||
[source,groovy,indent=0,subs="verbatim,attributes",role="secondary"]
|
||||
.Gradle
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/build.gradle[tags=deps_repos,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
For simplicity, we use the following acronyms:
|
||||
@@ -926,10 +946,12 @@ The following listing shows a test that we might use to check whether a loan amo
|
||||
large:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=client_tdd,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Assume that you have written a test of your new feature. If a loan application for a big
|
||||
@@ -944,10 +966,12 @@ client wants to borrow. You want to send it to the `/fraudcheck` URL by using th
|
||||
To do so, you might use code similar to the following:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/main/java/com/example/loan/LoanApplicationService.java[tags=client_call_server,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
For simplicity, the port of the Fraud Detection service is set to `8080`, and the
|
||||
@@ -981,17 +1005,21 @@ is important because the producer's test base class name references that folder.
|
||||
The following example shows our contract, in both Groovy and YAML:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0,role="primary"]
|
||||
.groovy
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[]
|
||||
----
|
||||
////
|
||||
|
||||
////
|
||||
[source,yaml,indent=0,role="secondary"]
|
||||
.yaml
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
The YML contract is quite straightforward. However, when you take a look at the contract
|
||||
@@ -1029,19 +1057,23 @@ We can add either a Maven or a Gradle plugin. In this example, we show how to ad
|
||||
First, we add the `Spring Cloud Contract` BOM, as the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_bom,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Next, add the `Spring Cloud Contract Verifier` Maven plugin, as the following example shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Since the plugin was added, you get the `Spring Cloud Contract Verifier` features, which,
|
||||
@@ -1103,19 +1135,23 @@ Application service`):
|
||||
. Add the `Spring Cloud Contract` BOM, as follows:
|
||||
+
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=contract_bom,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
. Add the dependency to `Spring Cloud Contract Stub Runner`, as follows:
|
||||
+
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
. Annotate your test class with `@AutoConfigureStubRunner`. In the annotation, provide the
|
||||
@@ -1123,10 +1159,12 @@ include::{introduction_url}/samples/standalone/dsl/http-client/pom.xml[tags=stub
|
||||
collaborators.
|
||||
+
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=autoconfigure_stubrunner,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
. (Optional) Because you are playing with the collaborators offline, you
|
||||
@@ -1199,12 +1237,14 @@ The following UML diagram shows the fraud detection flow:
|
||||
As a reminder, the following listing shows the initial implementation:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0]
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0]
|
||||
}
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Then you can run the following commands:
|
||||
@@ -1220,19 +1260,23 @@ $ git pull https://your-git-server.com/server-side-fork.git contract-change-pr
|
||||
You must add the dependencies needed by the autogenerated tests, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
In the configuration of the Maven plugin, you must pass the `packageWithBaseClasses` property, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
IMPORTANT: This example uses "`convention-based`" naming by setting the
|
||||
@@ -1248,10 +1292,12 @@ start the server side `FraudDetectionController`. The following listing shows th
|
||||
`FraudBase` class:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBase.java[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Now, if you run the `./mvnw clean install`, you get something like the following output:
|
||||
@@ -1312,6 +1358,7 @@ Because you know the expected input and expected output, you can write the missi
|
||||
implementation as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0]
|
||||
@@ -1319,6 +1366,7 @@ include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com
|
||||
include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0]
|
||||
}
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
When you run `./mvnw clean install` again, the tests pass. Since the Spring Cloud
|
||||
@@ -1392,10 +1440,12 @@ side are automatically downloaded from Nexus/Artifactory. You can set the value
|
||||
achieving the same thing by changing the properties:
|
||||
|
||||
====
|
||||
////
|
||||
[source,yaml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
That's it. You have finished the tutorial.
|
||||
|
||||
@@ -174,11 +174,13 @@ You can add the additional snapshot repository to your `settings.gradle` to use
|
||||
which are automatically uploaded after every successful build, as the following listing shows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{standalone_samples_path}/http-server/settings.gradle[tags=repos,indent=0]
|
||||
}
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[gradle-add-stubs]]
|
||||
@@ -400,10 +402,12 @@ specification for all generated acceptance tests. In this class, you need to poi
|
||||
endpoint, which should be verified. The following example shows how to do so:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/resources/functionalTest/bootSimple/src/test/groovy/org/springframework/cloud/contract/verifier/twitter/places/BaseMockMvcSpec.groovy[tags=base_class,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
If you use `Explicit` mode, you can use a base class to initialize the whole tested application,
|
||||
@@ -431,10 +435,12 @@ forms a class with a `Base` suffix. This rule takes precedence over `baseClassFo
|
||||
The following example shows how it works in the `contracts` closure:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/groovy/org/springframework/cloud/contract/verifier/plugin/ContractVerifierSpec.groovy[tags=package_with_base_classes,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
=== By Mapping
|
||||
@@ -445,10 +451,12 @@ name of the base class for the matched contract. You have to provide a list call
|
||||
`contractPackageRegex` to `baseClassFQN` mapping. Consider the following example:
|
||||
|
||||
====
|
||||
////
|
||||
[source,groovy,indent=0]
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-gradle-plugin/src/test/groovy/org/springframework/cloud/contract/verifier/plugin/ContractVerifierSpec.groovy[tags=base_class_mappings,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Assume that you have contracts in the following directories:
|
||||
|
||||
@@ -290,10 +290,12 @@ one-to-one to the contents of the repository.
|
||||
The following example shows a `pom.xml` file inside the `server` folder:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/contracts/com/example/server/pom.xml[indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
There are no dependencies other than the Spring Cloud Contract Maven Plugin.
|
||||
@@ -303,20 +305,24 @@ the stubs of the producer project.
|
||||
The `pom.xml` file in the root folder can look like the following:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/contracts/pom.xml[indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
It uses the assembly plugin to build the JAR with all the contracts. The following example
|
||||
shows such a setup:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/samples/standalone/contracts/src/assembly/contracts.xml[indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[how-to-workflow]]
|
||||
@@ -379,10 +385,12 @@ As a producer, you can alter the Spring Cloud Contract Verifier to provide the U
|
||||
the dependency of the JAR that contains the contracts, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{introduction_url}/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/basic-remote-contracts/pom-with-repo.xml[tags=remote_config,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
With this setup, the JAR with a `groupid` of `com.example.standalone` and an `artifactid` of
|
||||
@@ -770,6 +778,7 @@ contracts locally, with the producer, and only push the contracts and the stubs
|
||||
The following listing shows the setup required to achieve this with Maven and Gradle:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,role="primary"]
|
||||
.Maven
|
||||
----
|
||||
@@ -781,6 +790,7 @@ include::{samples_url}/producer_with_empty_git/pom.xml[tags=plugin,indent=0]
|
||||
----
|
||||
include::{samples_url}/producer_with_empty_git/build.gradle[tags=plugin,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
With such a setup:
|
||||
@@ -875,10 +885,12 @@ Spring Cloud Contract can read the Pact JSON definition. You can place the file
|
||||
`src/test/resources/contracts` folder. Remember to put the `spring-cloud-contract-pact` dependency to your classpath. The following example shows such a Pact contract:
|
||||
|
||||
====
|
||||
////
|
||||
[source,javascript,indent=0]
|
||||
----
|
||||
include::{standalone_pact_path}/http-server/src/test/resources/contracts/pact/shouldMarkClientAsFraud.json[indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[how-to-use-pact-broker-pact-for-producers]]
|
||||
@@ -890,6 +902,7 @@ the current Pact version that you use. The following listing shows how to do so
|
||||
Maven and Gradle:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Maven
|
||||
----
|
||||
@@ -901,6 +914,7 @@ include::{standalone_pact_path}/http-server/pom.xml[tags=pact_dependency,indent=
|
||||
----
|
||||
include::{standalone_pact_path}/http-server/build.gradle[tags=pact_dependency,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
When you build your application, a test and stub is generated. The following
|
||||
@@ -973,6 +987,7 @@ current Pact version that you use. The following listing shows how to do so for
|
||||
Maven and Gradle:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.Maven
|
||||
----
|
||||
@@ -984,6 +999,7 @@ include::{standalone_pact_path}/http-client/pom.xml[tags=pact_dependency,indent=
|
||||
----
|
||||
include::{standalone_pact_path}/http-client/build.gradle[tags=pact_dependency,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[pact-stub-downloader]]
|
||||
@@ -1432,6 +1448,7 @@ you only need to make some minor changes to your setup if you are using MockMvc
|
||||
To do so, include the following dependencies (if you have not already done so):
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.maven
|
||||
----
|
||||
@@ -1443,12 +1460,14 @@ include::{standalone_restdocs_path}/http-server/pom.xml[tags=dependencies,indent
|
||||
----
|
||||
include::{standalone_restdocs_path}/http-server/build.gradle[tags=dependencies,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Next, you need to make some changes to your base class. The following examples use
|
||||
`WebAppContext` and the standalone option with RestAssured:
|
||||
|
||||
====
|
||||
////
|
||||
[source,java,indent=0,subs="verbatim,attributes",role="primary"]
|
||||
.WebAppContext
|
||||
----
|
||||
@@ -1460,6 +1479,7 @@ include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/
|
||||
----
|
||||
include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/FraudBaseWithStandaloneSetup.java[tags=base_class,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
TIP: You need not specify the output directory for the generated snippets (since version 1.2.0.RELEASE of Spring REST Docs).
|
||||
|
||||
@@ -25,19 +25,23 @@ You can also check the plugin's documentation link:../../spring-cloud-contract-m
|
||||
To add the Spring Cloud Contract BOM, include the following section in your `pom.xml` file:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{standalone_samples_path}/http-server/pom.xml[tags=contract_bom,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Next, add the `Spring Cloud Contract Verifier` Maven plugin, as follows:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{standalone_samples_path}/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
You can read more in the
|
||||
@@ -137,10 +141,12 @@ To use Snapshot and Milestone versions, you have to add the following section to
|
||||
`pom.xml`:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
[[maven-add-stubs]]
|
||||
@@ -394,10 +400,12 @@ forms a class with a `Base` suffix. This rule takes precedence over `baseClassFo
|
||||
The following example shows how it works in the `contracts` closure:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/basic-generated-baseclass/pom.xml[tags=convention,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
=== By Mapping
|
||||
@@ -408,10 +416,12 @@ name of the base class for the matched contract. You have to provide a list call
|
||||
`contractPackageRegex` to `baseClassFQN` mapping. Consider the following example:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{plugins_path}/spring-cloud-contract-maven-plugin/src/test/projects/basic-baseclass-from-mappings/pom.xml[tags=mapping,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Assume that you have contracts under these two locations:
|
||||
@@ -641,10 +651,12 @@ path where your base test classes are defined and the path were the generated co
|
||||
The following example shows how to do so:
|
||||
|
||||
====
|
||||
////
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
include::{samples_url}/producer_with_spock/pom.xml[tags=gmavenplus-setup,indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
If you uphold the Spock convention of ending the test class names with `Spec`, you also need to adjust your Maven
|
||||
|
||||
@@ -5,8 +5,10 @@ include::_attributes.adoc[]
|
||||
Below you can find a JSON schema definition of a YAML contract.
|
||||
|
||||
====
|
||||
////
|
||||
[source,json,indent=0]
|
||||
----
|
||||
include::{project-root}/docs/target/contract_schema.json[indent=0]
|
||||
----
|
||||
////
|
||||
====
|
||||
|
||||
Reference in New Issue
Block a user