SpringCloud/spring-cloud-contract
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Removed reference in the docs to samples

Browse Source
This commit is contained in:
Marcin Grzejszczak
2024-10-04 11:45:26 +02:00
parent aeb82b1b9e
commit c16901fb51
19 changed files with 96 additions and 260 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/modules/ROOT/pages/building.adoc
View File

@@ -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:

5
docs/modules/ROOT/pages/customization/wiremock-customization.adoc
View File

@@ -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.

4
docs/modules/ROOT/pages/docker-project.adoc
View File

@@ -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

104
docs/modules/ROOT/pages/getting-started/cdc.adoc
View File

@@ -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.

25
docs/modules/ROOT/pages/getting-started/first-application.adoc
View File

@@ -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

18
docs/modules/ROOT/pages/getting-started/introducing-spring-cloud-contract.adoc
View File

@@ -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.

15
docs/modules/ROOT/pages/getting-started/three-second-tour.adoc
View File

@@ -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

11
docs/modules/ROOT/pages/gradle-project.adoc
View File

@@ -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

34
docs/modules/ROOT/pages/howto/contract-dsl-rest-docs.adoc
View File

@@ -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).

15
docs/modules/ROOT/pages/howto/how-to-common-repo-with-contracts.adoc
View File

@@ -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

3
docs/modules/ROOT/pages/howto/how-to-use-git-as-storage.adoc
View File

@@ -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:

55
docs/modules/ROOT/pages/maven-project.adoc
View File

@@ -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]
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-dependencies</artifactId>
<version>${spring-cloud-contract.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
----
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]
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
<configuration>
<packageWithBaseClasses>com.example.fraud</packageWithBaseClasses>
</configuration>
</plugin>
----
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]
<repositories>
<repository>
<id>spring-snapshots</id>
<name>Spring Snapshots</name>
<url>https://repo.spring.io/snapshot</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
<repository>
<id>spring-milestones</id>
<name>Spring Milestones</name>
<url>https://repo.spring.io/milestone</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>spring-snapshots</id>
<name>Spring Snapshots</name>
<url>https://repo.spring.io/snapshot</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>spring-milestones</id>
<name>Spring Milestones</name>
<url>https://repo.spring.io/milestone</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
----
[[maven-add-stubs]]

16
docs/modules/ROOT/pages/project-features-contract/common-top-elements.adoc
View File

@@ -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
----

15
docs/modules/ROOT/pages/project-features-stubrunner/stub-runner-snapshot-versions.adoc
View File

@@ -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]

9
docs/modules/ROOT/pages/using/cdc-external-repo.adoc
View File

@@ -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.

6
docs/modules/ROOT/pages/using/provider-contract-testing-non-spring.adoc
View File

@@ -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:

6
docs/modules/ROOT/pages/using/provider-contract-testing-rest-docs.adoc
View File

@@ -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.

6
docs/modules/ROOT/pages/using/provider-contract-testing-with-stubs-in-git.adoc
View File

@@ -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.

2
docs/modules/ROOT/partials/appProps.adoc
View File

@@ -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.|
|===