diff --git a/docs/modules/ROOT/pages/building.adoc b/docs/modules/ROOT/pages/building.adoc index ced98ca14e..b9a5eea9a5 100644 --- a/docs/modules/ROOT/pages/building.adoc +++ b/docs/modules/ROOT/pages/building.adoc @@ -71,8 +71,7 @@ The following list describes each of the top-level folders in the project struct - `config`: Folder contains setup for Spring Cloud Release Tools automated release process - `docker`: Folder contains docker images -- `samples`: Folder contains test samples together with standalone ones used also to build documentation -- `scripts`: Contains scripts to build and test `Spring Cloud Contract` with Maven, Gradle and standalone projects +- `scripts`: Contains scripts to build and test `Spring Cloud Contract` with Maven, Gradle - `specs`: Contains specifications for the Contract DSL. - `spring-cloud-contract-dependencies`: Contains Spring Cloud Contract BOM - `spring-cloud-contract-shade`: Shaded dependencies used by the plugins @@ -95,9 +94,7 @@ command: ./mvnw clean install -P integration ``` -Calling that function builds the core, the Maven plugin, and the Gradle plugin and runs -end-to_end tests on the -standalone samples in the proper order (both for Maven and Gradle). +Calling that function builds the core, the Maven plugin, and the Gradle plugin. To build only the Gradle Plugin, you can run the following commands: diff --git a/docs/modules/ROOT/pages/customization/wiremock-customization.adoc b/docs/modules/ROOT/pages/customization/wiremock-customization.adoc index b068b0eeff..dec1d5dfe9 100644 --- a/docs/modules/ROOT/pages/customization/wiremock-customization.adoc +++ b/docs/modules/ROOT/pages/customization/wiremock-customization.adoc @@ -52,10 +52,7 @@ With version 3.0.0 you're able to set `metadata` in your contracts. If you set a will be a valid WireMock's `StubMapping` JSON / map or an actual `StubMapping` object, Spring Cloud Contract will patch the generated stub with part of your customization. Let's look at the following example -[source,yaml,indent=0] ----- -include::{standalone_samples_path}/http-server/src/test/resources/contracts/yml/fraud/shouldReturnFraudStats.yml[tags=metadata,indent=0] ----- +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldReturnFraudStats.yml[Click here to see the code] In the `metadata` section we've set an entry with key `wiremock` and its value is a JSON `StubMapping` that sets a delay in the generated stub. Such code allowed us to get the following merged WireMock JSON stub. diff --git a/docs/modules/ROOT/pages/docker-project.adoc b/docs/modules/ROOT/pages/docker-project.adoc index 5c1c855c64..9d8874092a 100644 --- a/docs/modules/ROOT/pages/docker-project.adoc +++ b/docs/modules/ROOT/pages/docker-project.adoc @@ -180,8 +180,6 @@ in case of polyglot applications) then you'll have to have the following prerequ The contract needs to call a `triggerMessage(...)` method. That method is already provided in the base class for all tests in the docker image and will send out a request to the HTTP endpoint on the producer side. Below you can find examples of such contracts. -[tabs] -====== Groovy:: + [source,groovy,indent=0,subs="verbatim",role="primary"] @@ -240,7 +238,7 @@ metadata: messageProperties: receivedRoutingKey: '#' ---- -====== + [[docker-example-of-usage-messaging-endpoint]] ==== HTTP Endpoint to Trigger a Message diff --git a/docs/modules/ROOT/pages/getting-started/cdc.adoc b/docs/modules/ROOT/pages/getting-started/cdc.adoc index c0885bbb0d..85debd1317 100644 --- a/docs/modules/ROOT/pages/getting-started/cdc.adoc +++ b/docs/modules/ROOT/pages/getting-started/cdc.adoc @@ -24,7 +24,7 @@ Social remarks discuss changes while going through the process. * CDC is all about communication. -The server-side code is available under Spring Cloud Contract's repository `samples/standalone/dsl/http-server` path, and the client-side code is available under Spring Cloud Contract's repository `samples/standalone/dsl/http-client` path. +The server-side code is available under {samples_code}[Spring Cloud Contract Samples] repository `samples/standalone/dsl/http-server` path, and the client-side code is available under Spring Cloud Contract's repository `samples/standalone/dsl/http-client` path. TIP: In this case, the producer owns the contracts. Physically, all the contracts are in the producer's repository. @@ -32,26 +32,7 @@ in the producer's repository. [[getting-started-cdc-technical-note]] == Technical Note -If you use the SNAPSHOT, Milestone, or Release Candidate versions, you need to add the -following section to your build: - -[tabs] -====== -Maven:: -+ -[source,xml,indent=0,subs="verbatim",role="primary"] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=repos,indent=0] ----- -====== -//// - -//// -[source,groovy,indent=0,subs="verbatim",role="secondary"] -.Gradle ----- -include::{samples_path}/standalone/dsl/http-server/build.gradle[tags=deps_repos,indent=0] ----- +IMPORTANT:All the code is available under {samples_code}[spring Cloud Contract Samples repo]. For simplicity, we use the following acronyms: @@ -113,10 +94,7 @@ We start with the loan issuance flow, which the following UML diagram shows: The following listing shows a test that we might use to check whether a loan amount is too large: -[source,groovy,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=client_tdd,indent=0] ----- +{samples_code}/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[Click here to see the code] Assume that you have written a test of your new feature. If a loan application for a big amount is received, the system should reject that loan application with some description. @@ -129,10 +107,7 @@ that you need to send the request containing the ID of the client and the amount client wants to borrow. You want to send it to the `/fraudcheck` URL by using the `PUT` method. To do so, you might use code similar to the following: -[source,groovy,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/src/main/java/com/example/loan/LoanApplicationService.java[tags=client_call_server,indent=0] ----- +{samples_code}/standalone/dsl/http-client/src/main/java/com/example/loan/LoanApplicationService.java[Click here to see the code] For simplicity, the port of the Fraud Detection service is set to `8080`, and the application runs on `8090`. @@ -162,16 +137,9 @@ 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"] ----- -include::{samples_path}/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[] ----- +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[Click here to see the Groovy code] -[source,yaml,indent=0,role="secondary"] -.yaml ----- -include::{samples_path}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[] ----- +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[Click here to see the YAML code] The YML contract is quite straightforward. However, when you take a look at the contract written with a statically typed Groovy DSL, you might wonder what the @@ -207,17 +175,11 @@ install the stubs locally. We can add either a Maven or a Gradle plugin. In this example, we show how to add Maven. First, we add the `Spring Cloud Contract` BOM, as the following example shows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=contract_bom,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] Next, add the `Spring Cloud Contract Verifier` Maven plugin, as the following example shows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] Since the plugin was added, you get the `Spring Cloud Contract Verifier` features, which, from the provided contracts: @@ -271,26 +233,17 @@ Application service`): . Add the `Spring Cloud Contract` BOM, as follows: + -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/pom.xml[tags=contract_bom,indent=0] ----- +{samples_code}/standalone/dsl/http-client/pom.xml[Click here to see the code] . Add the dependency to `Spring Cloud Contract Stub Runner`, as follows: + -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0] ----- +{samples_code}/standalone/dsl/http-client/pom.xml[Click here to see the code] . Annotate your test class with `@AutoConfigureStubRunner`. In the annotation, provide the `group-id` and `artifact-id` for the Stub Runner to download the stubs of your collaborators. + -[source,groovy,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[tags=autoconfigure_stubrunner,indent=0] ----- +{samples_code}/standalone/dsl/http-client/src/test/java/com/example/loan/LoanApplicationServiceTests.java[Click here to see the code] . (Optional) Because you are playing with the collaborators offline, you can also provide the offline work switch (`StubRunnerProperties.StubsMode.LOCAL`). @@ -359,12 +312,7 @@ The following UML diagram shows the fraud detection flow: As a reminder, the following listing shows the initial implementation: -[source,java,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0] -include::{samples_path}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0] -} ----- +{samples_code}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[Click here to see the code] Then you can run the following commands: @@ -376,17 +324,11 @@ $ 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::{samples_path}/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] In the configuration of the Maven plugin, you must pass the `packageWithBaseClasses` property, as follows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] IMPORTANT: This example uses "`convention-based`" naming by setting the `packageWithBaseClasses` property. Doing so means that the two last packages combine to @@ -400,10 +342,7 @@ or whatever is necessary. In this case, you should use https://github.com/rest-a start the server side `FraudDetectionController`. The following listing shows the `FraudBase` class: -[source,java,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBase.java[] ----- +{samples_code}/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBase.java[Click here to see the code] Now, if you run the `./mvnw clean install`, you get something like the following output: @@ -458,13 +397,7 @@ in the response. In other words, you have the `red` part of `red`, `green`, and Because you know the expected input and expected output, you can write the missing implementation as follows: -[source,java,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0] -include::{samples_path}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=new_impl,indent=0] -include::{samples_path}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0] -} ----- +{samples_code}/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[Click here to see the code] When you run `./mvnw clean install` again, the tests pass. Since the Spring Cloud Contract Verifier plugin adds the tests to the `generated-test-sources`, you can @@ -532,10 +465,7 @@ side are automatically downloaded from Nexus/Artifactory. You can set the value `stubsMode` to `REMOTE`. The following code shows an example of achieving the same thing by changing the properties: -[source,yaml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[] ----- +{samples_code}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[Click here to see the code] That's it. You have finished the tutorial. diff --git a/docs/modules/ROOT/pages/getting-started/first-application.adoc b/docs/modules/ROOT/pages/getting-started/first-application.adoc index f9cb08e385..89e409fe85 100644 --- a/docs/modules/ROOT/pages/getting-started/first-application.adoc +++ b/docs/modules/ROOT/pages/getting-started/first-application.adoc @@ -39,10 +39,7 @@ The following UML diagram shows the relationship of the parts of Spring Cloud Co To start working with `Spring Cloud Contract`, you can add the Spring Cloud Contract Verifier dependency and plugin to your build file, as the following example shows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] The following listing shows how to add the plugin, which should go in the build/plugins portion of the file: @@ -78,8 +75,6 @@ For the HTTP stubs, a contract defines what kind of response should be returned given request (taking into account the HTTP methods, URLs, headers, status codes, and so on). The following example shows an HTTP stub contract in both Groovy and YAML: -[tabs] -====== groovy:: + [source,groovy,indent=0,role="primary"] @@ -136,8 +131,6 @@ response: headers: Content-Type: application/json;charset=UTF-8 ---- -====== - If you need to use messaging, you can define: * The input and output messages (taking into account from where it @@ -147,8 +140,6 @@ was sent, the message body, and the header). The following example shows a Camel messaging contract: -[tabs] -====== groovy:: + [source,groovy,indent=0,role="primary"] @@ -162,7 +153,6 @@ yaml:: ---- include::{verifier_root_path}/src/test/resources/yml/contract_message_scenario1.yml[indent=0] ---- -====== Running `./mvnw clean install` automatically generates tests that verify the application compliance with the added contracts. By default, the generated tests are under @@ -183,8 +173,6 @@ of the other frameworks, add its library to your classpath. The following listing shows samples for all frameworks: -[tabs] -====== mockmvc:: + [source,java,indent=0,role="primary"] @@ -271,7 +259,6 @@ webtestclient:: assertThatJson(parsedJson).field("['status']").isEqualTo("NOT_OK"); } ---- -====== As the implementation of the functionalities described by the contracts is not yet present, the tests fail. @@ -432,10 +419,7 @@ 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::{samples_path}/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0] ----- +{samples_code}/standalone/dsl/http-client/pom.xml[Click here to see the code] You can get the Producer-side stubs installed in your Maven repository in either of two ways: @@ -455,10 +439,7 @@ in place, so the automatically-generated contract tests fail. 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::{samples_path}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[] ----- +{samples_code}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[Click here to see the code] Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation, provide the `group-id` and `artifact-id` for `Spring Cloud Contract Stub Runner` to run diff --git a/docs/modules/ROOT/pages/getting-started/introducing-spring-cloud-contract.adoc b/docs/modules/ROOT/pages/getting-started/introducing-spring-cloud-contract.adoc index 2f1a53bf74..6f1f4c12d7 100644 --- a/docs/modules/ROOT/pages/getting-started/introducing-spring-cloud-contract.adoc +++ b/docs/modules/ROOT/pages/getting-started/introducing-spring-cloud-contract.adoc @@ -108,23 +108,9 @@ amount it wants to borrow from us. You also want to send it to the `/fraudcheck` the `PUT` method. The following listing shows a contract to check whether a client should be marked as a fraud in both Groovy and YAML: -[tabs] -====== -groovy:: -+ -[source,groovy,indent=0,role="primary"] ----- -include::{samples_path}/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[] ----- -====== -//// +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldMarkClientAsFraud.groovy[Click here to see the Groovy Code] -//// -[source,yaml,indent=0,role="secondary"] -.yaml ----- -include::{samples_path}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[] ----- +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldMarkClientAsFraud.yml[Click here to see the YAML Code] IMPORTANT: It is expected that contracts are coming from a **trusted source**. You should never download nor interact with contracts coming from untrusted locations. diff --git a/docs/modules/ROOT/pages/getting-started/three-second-tour.adoc b/docs/modules/ROOT/pages/getting-started/three-second-tour.adoc index b35ebed07e..491ed0b748 100644 --- a/docs/modules/ROOT/pages/getting-started/three-second-tour.adoc +++ b/docs/modules/ROOT/pages/getting-started/three-second-tour.adoc @@ -42,10 +42,7 @@ expressed in either Groovy DSL or YAML to the contracts directory, which is set Then you can add the Spring Cloud Contract Verifier dependency and plugin to your build file, as the following example shows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the code] The following listing shows how to add the plugin, which should go in the build/plugins portion of the file: @@ -112,10 +109,7 @@ WireMock instance or messaging route that simulates the actual service. To do so, add the dependency to `Spring Cloud Contract Stub Runner`, as the following example shows: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/dsl/http-client/pom.xml[tags=stub_runner,indent=0] ----- +{samples_code}/standalone/dsl/http-client/pom.xml[Click here to see the code] You can get the Producer-side stubs installed in your Maven repository in either of two ways: @@ -136,10 +130,7 @@ in place yet, so the automatically-generated contract tests fail. 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::{samples_path}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[] ----- +{samples_code}/standalone/dsl/http-client/src/test/resources/application-test-repo.yaml[Click here to see the code] Now you can annotate your test class with `@AutoConfigureStubRunner`. In the annotation, provide the `group-id` and `artifact-id` values for `Spring Cloud Contract Stub Runner` to diff --git a/docs/modules/ROOT/pages/gradle-project.adoc b/docs/modules/ROOT/pages/gradle-project.adoc index e92952d3d3..a55fc481cf 100644 --- a/docs/modules/ROOT/pages/gradle-project.adoc +++ b/docs/modules/ROOT/pages/gradle-project.adoc @@ -18,8 +18,6 @@ documentation] for more information. To add a Gradle plugin with dependencies, you can use code similar to the following: -[tabs] -====== Plugin DSL GA versions:: + [source,groovy,indent=0,subs="verbatim",role="primary"] @@ -122,7 +120,6 @@ dependencies { testImplementation 'org.springframework.cloud:spring-cloud-starter-contract-verifier' } ---- -====== [[gradle-and-rest-assured]] == Gradle and Rest Assured 2.0 @@ -157,13 +154,7 @@ and modifies the imports accordingly. == Snapshot Versions for Gradle You can add the additional snapshot repository to your `settings.gradle` to use snapshot versions, -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] -} ----- +which are automatically uploaded after every successful build. [[gradle-add-stubs]] == Add stubs diff --git a/docs/modules/ROOT/pages/howto/contract-dsl-rest-docs.adoc b/docs/modules/ROOT/pages/howto/contract-dsl-rest-docs.adoc index f9f85542d5..67b55dc9c2 100644 --- a/docs/modules/ROOT/pages/howto/contract-dsl-rest-docs.adoc +++ b/docs/modules/ROOT/pages/howto/contract-dsl-rest-docs.adoc @@ -7,42 +7,16 @@ When you want to include the requests and responses of your API by using Spring you only need to make some minor changes to your setup if you are using MockMvc and RestAssuredMockMvc. To do so, include the following dependencies (if you have not already done so): -[tabs] -====== -maven:: -+ -[source,xml,indent=0,subs="verbatim",role="primary"] ----- -include::{standalone_restdocs_path}/http-server/pom.xml[tags=dependencies,indent=0] ----- +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the Maven code] -gradle:: -+ -[source,groovy,indent=0,subs="verbatim",role="secondary"] ----- -include::{standalone_restdocs_path}/http-server/build.gradle[tags=dependencies,indent=0] ----- -====== +{samples_code}/standalone/dsl/http-server/build.gradle[Click here to see the Gradle code] Next, you need to make some changes to your base class. The following examples use `WebAppContext` and the standalone option with RestAssured: -[tabs] -====== -WebAppContext:: -+ -[source,java,indent=0,subs="verbatim",role="primary"] ----- -include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/FraudBaseWithWebAppSetup.java[tags=base_class,indent=0] ----- +{samples_code}/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBaseWithWebAppSetup.java[Click here to see the WebAppContext code] -Standalone:: -+ -[source,java,indent=0,subs="verbatim",role="secondary"] ----- -include::{standalone_restdocs_path}/http-server/src/test/java/com/example/fraud/FraudBaseWithStandaloneSetup.java[tags=base_class,indent=0] ----- -====== +{samples_code}/standalone/dsl/http-server/src/test/java/com/example/fraud/FraudBaseWithStandaloneSetup.java[Click here to see the standalone code] TIP: You need not specify the output directory for the generated snippets (since version 1.2.0.RELEASE of Spring REST Docs). diff --git a/docs/modules/ROOT/pages/howto/how-to-common-repo-with-contracts.adoc b/docs/modules/ROOT/pages/howto/how-to-common-repo-with-contracts.adoc index ff37753571..d270fbedce 100644 --- a/docs/modules/ROOT/pages/howto/how-to-common-repo-with-contracts.adoc +++ b/docs/modules/ROOT/pages/howto/how-to-common-repo-with-contracts.adoc @@ -45,10 +45,7 @@ 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::{samples_path}/standalone/contracts/com/example/server/pom.xml[indent=0] ----- +{samples_code}/standalone/dsl/contracts/com/example/server/pom.xml[Click here to see the code] There are no dependencies other than the Spring Cloud Contract Maven Plugin. Those `pom.xml` files are necessary for the consumer side to run `mvn clean install -DskipTests` to locally install @@ -56,18 +53,12 @@ the stubs of the producer project. The `pom.xml` file in the root folder can look like the following: -[source,xml,indent=0] ----- -include::{samples_path}/standalone/contracts/pom.xml[indent=0] ----- +{samples_code}/standalone/dsl/contracts/pom.xml[Click here to see the code] 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::{samples_path}/standalone/contracts/src/assembly/contracts.xml[indent=0] ----- +{samples_code}/standalone/dsl/contracts/src/assembly/contracts.xml[Click here to see the code] [[how-to-workflow]] == Workflow diff --git a/docs/modules/ROOT/pages/howto/how-to-use-git-as-storage.adoc b/docs/modules/ROOT/pages/howto/how-to-use-git-as-storage.adoc index 05fcb339e6..3d6cf86c5c 100644 --- a/docs/modules/ROOT/pages/howto/how-to-use-git-as-storage.adoc +++ b/docs/modules/ROOT/pages/howto/how-to-use-git-as-storage.adoc @@ -95,8 +95,6 @@ repository. The following listing includes the relevant parts both Maven and Gradle build files: -[tabs] -====== Maven:: + [source,xml,indent=0,role="primary"] @@ -165,7 +163,6 @@ the `publish` task is invoked */ publish.dependsOn("publishStubsToScm") ---- -====== You can also further customize the `publishStubsToScm` gradle task. In the following example, the task is customized to pick contracts from a local git repository: diff --git a/docs/modules/ROOT/pages/maven-project.adoc b/docs/modules/ROOT/pages/maven-project.adoc index fb381e54e7..639b1e1804 100644 --- a/docs/modules/ROOT/pages/maven-project.adoc +++ b/docs/modules/ROOT/pages/maven-project.adoc @@ -10,14 +10,28 @@ To add the Spring Cloud Contract BOM, include the following section in your `pom [source,xml,indent=0] ---- -include::{standalone_samples_path}/http-server/pom.xml[tags=contract_bom,indent=0] + + org.springframework.cloud + spring-cloud-contract-dependencies + ${spring-cloud-contract.version} + pom + import + ---- 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] + + org.springframework.cloud + spring-cloud-contract-maven-plugin + ${spring-cloud-contract.version} + true + + com.example.fraud + + ---- You can read more in the @@ -114,7 +128,42 @@ To use Snapshot and Milestone versions, you have to add the following section to [source,xml,indent=0] ---- -include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0] + + + spring-snapshots + Spring Snapshots + https://repo.spring.io/snapshot + + true + + + + spring-milestones + Spring Milestones + https://repo.spring.io/milestone + + false + + + + + + spring-snapshots + Spring Snapshots + https://repo.spring.io/snapshot + + true + + + + spring-milestones + Spring Milestones + https://repo.spring.io/milestone + + false + + + ---- [[maven-add-stubs]] diff --git a/docs/modules/ROOT/pages/project-features-contract/common-top-elements.adoc b/docs/modules/ROOT/pages/project-features-contract/common-top-elements.adoc index cd31acb2a4..47f9d5e8c0 100644 --- a/docs/modules/ROOT/pages/project-features-contract/common-top-elements.adoc +++ b/docs/modules/ROOT/pages/project-features-contract/common-top-elements.adoc @@ -263,19 +263,11 @@ an example of using the `wiremock` key. Its value is a map whose key is `stubMap patch parts of your generated stub mapping with your custom code. You may want to do that in order to add webhooks, custom delays or integrate with third party WireMock extensions. +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/fraud/shouldReturnFraudStats.groovy[Click here to see the Groovy code] + +{samples_code}/standalone/dsl/http-server/src/test/resources/contracts/yml/fraud/shouldReturnFraudStats.yml[Click here to see the YAML code] + ==== -[source,groovy,indent=0,role="primary"] -.groovy ----- -include::{standalone_samples_path}/http-server/src/test/resources/contracts/fraud/shouldReturnFraudStats.groovy[tags=metadata,indent=0] ----- - -[source,yaml,indent=0,role="secondary"] -.yml ----- -include::{standalone_samples_path}/http-server/src/test/resources/contracts/yml/fraud/shouldReturnFraudStats.yml[tags=metadata,indent=0] ----- - [source,java,indent=0,subs="verbatim",role="secondary"] .java ---- diff --git a/docs/modules/ROOT/pages/project-features-stubrunner/stub-runner-snapshot-versions.adoc b/docs/modules/ROOT/pages/project-features-stubrunner/stub-runner-snapshot-versions.adoc index cc75686954..76e8c6a358 100644 --- a/docs/modules/ROOT/pages/project-features-stubrunner/stub-runner-snapshot-versions.adoc +++ b/docs/modules/ROOT/pages/project-features-stubrunner/stub-runner-snapshot-versions.adoc @@ -7,17 +7,6 @@ include::partial$_attributes.adoc[] You can add the additional snapshot repository to your build file to use snapshot versions, which are automatically uploaded after every successful build, as follows: -==== -[source,xml,indent=0,subs="verbatim",role="primary"] -.Maven ----- -include::{standalone_samples_path}/http-server/pom.xml[tags=repos,indent=0] ----- - -[source,groovy,indent=0,subs="verbatim",role="secondary"] -.Gradle (`settings.xml`) ----- -include::{standalone_samples_path}/http-server/settings.gradle[tags=repos,indent=0] ----- -==== +{samples_code}/standalone/dsl/http-server/pom.xml[Click here to see the Maven code] +{samples_code}/standalone/dsl/http-server/settings.gradle[Click here to see the Gradle code] diff --git a/docs/modules/ROOT/pages/using/cdc-external-repo.adoc b/docs/modules/ROOT/pages/using/cdc-external-repo.adoc index 24eba96119..c85d2fa012 100644 --- a/docs/modules/ROOT/pages/using/cdc-external-repo.adoc +++ b/docs/modules/ROOT/pages/using/cdc-external-repo.adoc @@ -114,8 +114,6 @@ $ ./mvnw clean install . Sets up the plugin to fetch the contract definitions from a JAR instead of from `src/test/resources/contracts`, as follows: + -[tabs] -=== Maven:: + [source,xml,indent=0,subs="verbatim",role="primary"] @@ -153,11 +151,8 @@ contracts { // Additional configuration } ---- -=== . Runs the build to generate tests and stubs, as follows: + -[tabs] -=== Maven:: + [source,bash,indent=0,subs="verbatim",role="primary"] @@ -171,7 +166,6 @@ Gradle:: ---- ./gradlew clean build ---- -=== . Writes the missing implementation, to make the tests pass. . Merges the pull request to the repository with contract definitions, as follows: + @@ -189,8 +183,6 @@ the contract definitions to Nexus or Artifactory. . Sets up the plugin so that the contract definitions are no longer taken from the local storage but from a remote location, as follows: + -[tabs] -=== Maven:: + [source,xml,indent=0,subs="verbatim",role="primary"] @@ -228,7 +220,6 @@ contracts { // Additional configuration } ---- -=== . Merges the producer code with the new implementation. . The CI system: ** Builds the project. diff --git a/docs/modules/ROOT/pages/using/provider-contract-testing-non-spring.adoc b/docs/modules/ROOT/pages/using/provider-contract-testing-non-spring.adoc index 9be858aa9a..d86bcbc6d1 100644 --- a/docs/modules/ROOT/pages/using/provider-contract-testing-non-spring.adoc +++ b/docs/modules/ROOT/pages/using/provider-contract-testing-non-spring.adoc @@ -15,8 +15,6 @@ You can read xref:getting-started/first-application.adoc[Developing Your First S For the consumer side, you can use a JUnit rule. That way, you need not start a Spring context. The following listing shows such a rule (in JUnit4 and JUnit 5); -[tabs] -=== JUnit 4 Rule:: + [source,java,indent=0,subs="verbatim",role="primary"] @@ -38,7 +36,6 @@ JUnit 5 Extension:: .repoRoot("git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git") .stubsMode(StubRunnerProperties.StubsMode.REMOTE); ---- -=== [[flows-provider-non-spring-producer]] == Setting up the Producer @@ -82,8 +79,6 @@ public class DemoApplication { Given that application, we can set up the plugin to use the `EXPLICIT` mode (that is, to send out requests to a real port), as follows: -[tabs] -=== Maven:: + [source,xml,indent=0,role="primary"] @@ -111,7 +106,6 @@ contracts { baseClassForTests = "com.example.demo.BaseClass" } ---- -=== The base class might resemble the following: diff --git a/docs/modules/ROOT/pages/using/provider-contract-testing-rest-docs.adoc b/docs/modules/ROOT/pages/using/provider-contract-testing-rest-docs.adoc index 1a06b4f263..70daafc19d 100644 --- a/docs/modules/ROOT/pages/using/provider-contract-testing-rest-docs.adoc +++ b/docs/modules/ROOT/pages/using/provider-contract-testing-rest-docs.adoc @@ -13,8 +13,6 @@ As a producer, we: . Write RESTDocs tests of our API. . Add Spring Cloud Contract Stub Runner starter to our build (`spring-cloud-starter-contract-stub-runner`), as follows: + -[tabs] -====== Maven:: + [source,xml,indent=0,role="primary"] @@ -54,11 +52,8 @@ dependencyManagement { } } ---- -====== . We set up the build tool to package our stubs, as follows: + -[tabs] -====== Maven:: + [source,xml,indent=0,role="primary"] @@ -124,7 +119,6 @@ task stubsJar(type: Jar) { stubsJar.dependsOn(test) bootJar.dependsOn(stubsJar) ---- -====== Now, when we run the tests, stubs are automatically published and packaged. diff --git a/docs/modules/ROOT/pages/using/provider-contract-testing-with-stubs-in-git.adoc b/docs/modules/ROOT/pages/using/provider-contract-testing-with-stubs-in-git.adoc index 0523076bc3..d14594ae24 100644 --- a/docs/modules/ROOT/pages/using/provider-contract-testing-with-stubs-in-git.adoc +++ b/docs/modules/ROOT/pages/using/provider-contract-testing-with-stubs-in-git.adoc @@ -49,8 +49,6 @@ In order to fetch the stubs from a git repository instead of Nexus or Artifactor need to use the `git` protocol in the URL of the `repositoryRoot` property in Stub Runner. The following example shows how to set it up: -[tabs] -=== Annotation:: + [source,java,indent=0,subs="verbatim",role="primary"] @@ -82,7 +80,6 @@ JUnit 5 Extension:: .repoRoot("git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git") .stubsMode(StubRunnerProperties.StubsMode.REMOTE); ---- -=== [[flows-provider-git-producer]] == Setting up the Producer @@ -92,8 +89,6 @@ to use the `git` protocol in the URL of the plugin setup. Also you need to expli the plugin to push the stubs at the end of the build process. The following examples show how to do so in both Maven and Gradle: -[tabs] -=== Maven:: + [source,xml,indent=0,role="primary"] @@ -162,7 +157,6 @@ the `publish` task is run */ publish.dependsOn("publishStubsToScm") ---- -=== You can read more about setting up a git repository in the xref:../howto/how-to-use-git-as-storage.adoc[How To section] of the documentation. \ No newline at end of file diff --git a/docs/modules/ROOT/partials/appProps.adoc b/docs/modules/ROOT/partials/appProps.adoc index 189a4437dd..e8be5b1b43 100644 --- a/docs/modules/ROOT/partials/appProps.adoc +++ b/docs/modules/ROOT/partials/appProps.adoc @@ -6,8 +6,8 @@ |APPLICATION_USERNAME|Optional username to access the application.| |MESSAGING_TRIGGER_CONNECT_TIMEOUT|Timeout to connect to the application to trigger a message.|5000 |MESSAGING_TRIGGER_READ_TIMEOUT|Timeout to read the response from the application to trigger a message.|5000 -|MESSAGING_TYPE|Defines the messaging type when dealing with message based contracts.| |MESSAGING_TYPE|Type of messaging. Can be either [rabbit] or [kafka].| +|MESSAGING_TYPE|Defines the messaging type when dealing with message based contracts.| |SPRING_KAFKA_BOOTSTRAP_SERVERS|For Kafka - brokers addresses.| |SPRING_RABBITMQ_ADDRESSES|For RabbitMQ - brokers addresses.| |=== \ No newline at end of file