From 2d3402d0a881510d3de764c215dcdd0656f87f00 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 3 Jun 2019 18:02:50 +0000 Subject: [PATCH] Sync docs from 2.1.x to gh-pages --- .../multi__spring_cloud_contract_faq.html | 8 +++--- ...ti__spring_cloud_contract_stub_runner.html | 6 ++-- ..._cloud_contract_verifier_introduction.html | 8 +++--- ..._spring_cloud_contract_verifier_setup.html | 2 +- ...multi__spring_cloud_contract_wiremock.html | 2 +- 2.1.x/single/spring-cloud-contract.html | 26 ++++++++--------- .../index.html | 4 +-- .../junit.html | 2 +- .../spock.html | 2 +- 2.1.x/spring-cloud-contract.xml | 28 +++++++++---------- 10 files changed, 44 insertions(+), 44 deletions(-) diff --git a/2.1.x/multi/multi__spring_cloud_contract_faq.html b/2.1.x/multi/multi__spring_cloud_contract_faq.html index 863cdd094f..9a9f044dbf 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_faq.html +++ b/2.1.x/multi/multi__spring_cloud_contract_faq.html @@ -82,7 +82,7 @@ It can be related to security issues where the consumers can’t clone the p contracts in a single place then you, as a producer, will know how many consumers you have and which consumer you will break with your local changes.

3.5.1 Repo structure

Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup -(which you can checkout here):

├── com
+(which you can checkout here):
├── com
 │   └── example
 │       └── server
 │           ├── client1
@@ -116,15 +116,15 @@ one to one to the contents of the repo.
Example of a <parent>
 		<groupId>org.springframework.boot</groupId>
 		<artifactId>spring-boot-starter-parent</artifactId>
-		<version>2.2.0.BUILD-SNAPSHOT</version>
+		<version>2.1.3.RELEASE</version>
 		<relativePath/>
 	</parent>
 
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>2.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
-		<spring-cloud-release.version>Hoxton.BUILD-SNAPSHOT
+		<spring-cloud-contract.version>2.1.2.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-release.version>Greenwich.BUILD-SNAPSHOT
 		</spring-cloud-release.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
diff --git a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
index fcf0d6b529..b3e4488378 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html
@@ -207,8 +207,8 @@ producer stubs.

The producer would setup the contr    └── com.example       └── beer-api-producer-restdocs       └── nested -       └── contract3.groovy

To achieve proper stub packaging.

Or using the Maven assembly plugin or -Gradle Jar task you have to create the following +       └── contract3.groovy

To achieve proper stub packaging.

Or using the Maven assembly plugin or +Gradle Jar task you have to create the following structure in your stubs jar.

└── META-INF
     └── com.example
         └── beer-api-producer-restdocs
@@ -614,7 +614,7 @@ Value of the annotation can be the groupid:artifactidcom.example:foo, com.example:bar.
@StubRunnerPort("foo")
 int fooPort;
 @StubRunnerPort("com.example:bar")
-int barPort;
6.5 Stub Runner Spring Cloud
Stub Runner can integrate with Spring Cloud.
For real life examples you can check the
6.5.1 Stubbing Service Discovery
The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing
  • DiscoveryClient
  • Ribbon ServerList
that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests.
+int barPort;

6.5 Stub Runner Spring Cloud

Stub Runner can integrate with Spring Cloud.

For real life examples you can check the

6.5.1 Stubbing Service Discovery

The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

  • DiscoveryClient
  • Ribbon ServerList

that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using Feign, load balanced RestTemplate or DiscoveryClient directly, to call those stubbed servers instead of calling the real Service Discovery tool.

For example this test will pass

def 'should make service discovery work'() {
 	expect: 'WireMocks are running'
diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
index 06a5e4824c..a73e496f99 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -10,14 +10,14 @@ own integrations.
  • Acceptance tests (in JUnit 4, JUnit 5
 of the API is compliant with the contract (server tests). A full test is generated by
 Spring Cloud Contract Verifier.

    • 2.1 History

    Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (Codearte.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +from (Codearte.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.3 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both @@ -425,8 +425,8 @@ us. The current implementation of our system grants loans to everybody.

      As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.

      Technical remark - Fraud Detection has an artifact-id of http-server, while Loan Issuance has an artifact-id of http-client, and both have a group-id of com.example.

      Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.

      The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.

      The server +side code is available here and the client code here.

      [Tip]Tip

      In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.

      2.5.1 Technical note

      If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

      Maven.  diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html index 1afb2e5d91..82e32a106e 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html +++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html @@ -544,7 +544,7 @@ goal. Example:

      </plugin>

      Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible configuration options that you can pass either via the <configuration><contractProperties> map, a system property -or an environment variable.

      4.2.12 Maven Plugin and STS

      If you see the following exception while using STS:

      STS Exception

      When you click on the error marker you should see something like this:

       plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+or an environment variable.

      4.2.12 Maven Plugin and STS

      If you see the following exception while using STS:

      STS Exception

      When you click on the error marker you should see something like this:

       plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
diff --git a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html
index 8ba9456064..cef802f7be 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html
@@ -2,7 +2,7 @@
       
    11. Spring Cloud Contract WireMock
      11. Spring Cloud Contract WireMock
      Prev   Next
      11. Spring Cloud Contract WireMock
      The Spring Cloud Contract WireMock modules let you use WireMock in a
 Spring Boot application. Check out the
-samples
+samples
 for more details.
      If you have a Spring Boot application that uses Tomcat as an embedded server (which is
 the default with spring-boot-starter-web),  you can add
 spring-cloud-starter-contract-stub-runner to your classpath and add @AutoConfigureWireMock in
diff --git a/2.1.x/single/spring-cloud-contract.html b/2.1.x/single/spring-cloud-contract.html
index 8209c27114..aadfc7f824 100644
--- a/2.1.x/single/spring-cloud-contract.html
+++ b/2.1.x/single/spring-cloud-contract.html
@@ -15,14 +15,14 @@ own integrations.
    • Acceptance tests (in JUnit 4, JUnit 5 of the API is compliant with the contract (server tests). A full test is generated by Spring Cloud Contract Verifier.

    2.1 History

    Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (Codearte.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +from (Codearte.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with reality.
    • You can go to production with passing tests and failing production.

    To solve the aforementioned issues, Spring Cloud Contract Verifier with Stub Runner was created. The main idea is to give you very fast feedback, without the need to set up the whole world of microservices. If you work on stubs, then the only applications you need -are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were +are those that your application directly uses.

    Stubbed Services

    Spring Cloud Contract Verifier gives you the certainty that the stubs that you use were created by the service that you’re calling. Also, if you can use them, it means that they were tested against the producer’s side. In short, you can trust those stubs.

    2.3 Purposes

    The main purposes of Spring Cloud Contract Verifier with Stub Runner are:

    • To ensure that WireMock/Messaging stubs (used when developing the client) do exactly what the actual server-side implementation does.
    • To promote ATDD method and Microservices architectural style.
    • To provide a way to publish changes in contracts that are immediately visible on both @@ -430,8 +430,8 @@ us. The current implementation of our system grants loans to everybody.

      As sprint, we must develop a new feature: if a client wants to borrow too much money, then we mark the client as a fraud.

      Technical remark - Fraud Detection has an artifact-id of http-server, while Loan Issuance has an artifact-id of http-client, and both have a group-id of com.example.

      Social remark - both client and server development teams need to communicate directly and -discuss changes while going through the process. CDC is all about communication.

      The server -side code is available here and the +discuss changes while going through the process. CDC is all about communication.

      The server +side code is available here and the client code here.

      [Tip]Tip

      In this case, the producer owns the contracts. Physically, all the contract are in the producer’s repository.

      2.5.1 Technical note

      If using the SNAPSHOT / Milestone / Release Candidate versions please add the following section to your build:

      Maven.  @@ -927,7 +927,7 @@ It can be related to security issues where the consumers can’t clone the p contracts in a single place then you, as a producer, will know how many consumers you have and which consumer you will break with your local changes.

      3.5.1 Repo structure

      Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup -(which you can checkout here):

      ├── com
+(which you can checkout here):
      ├── com
 │   └── example
 │       └── server
 │           ├── client1
@@ -961,15 +961,15 @@ one to one to the contents of the repo.
      Example of a <parent>
 		<groupId>org.springframework.boot</groupId>
 		<artifactId>spring-boot-starter-parent</artifactId>
-		<version>2.2.0.BUILD-SNAPSHOT</version>
+		<version>2.1.3.RELEASE</version>
 		<relativePath/>
 	</parent>
 
 	<properties>
 		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 		<java.version>1.8</java.version>
-		<spring-cloud-contract.version>2.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version>
-		<spring-cloud-release.version>Hoxton.BUILD-SNAPSHOT
+		<spring-cloud-contract.version>2.1.2.BUILD-SNAPSHOT</spring-cloud-contract.version>
+		<spring-cloud-release.version>Greenwich.BUILD-SNAPSHOT
 		</spring-cloud-release.version>
 		<excludeBuildFolders>true</excludeBuildFolders>
 	</properties>
@@ -2088,7 +2088,7 @@ goal. Example:
      </plugin>
      Under Section 10.6, “Using the SCM Stub Downloader” you can find all possible
 configuration options that you can pass either via
 the <configuration><contractProperties> map, a system property
-or an environment variable.

      4.2.12 Maven Plugin and STS

      If you see the following exception while using STS:

      STS Exception

      When you click on the error marker you should see something like this:

       plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
+or an environment variable.

      4.2.12 Maven Plugin and STS

      If you see the following exception while using STS:

      STS Exception

      When you click on the error marker you should see something like this:

       plugin:1.1.0.M1:convert:default-convert:process-test-resources) org.apache.maven.plugin.PluginExecutionException: Execution default-convert of goal org.springframework.cloud:spring-
  cloud-contract-maven-plugin:1.1.0.M1:convert failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145) at
  org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331) at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362) at
 ...
@@ -2699,8 +2699,8 @@ producer stubs.

      The producer would setup the contr    └── com.example       └── beer-api-producer-restdocs       └── nested -       └── contract3.groovy

      To achieve proper stub packaging.

      Or using the Maven assembly plugin or -Gradle Jar task you have to create the following +       └── contract3.groovy

      To achieve proper stub packaging.

      Or using the Maven assembly plugin or +Gradle Jar task you have to create the following structure in your stubs jar.

      └── META-INF
     └── com.example
         └── beer-api-producer-restdocs
@@ -3106,7 +3106,7 @@ Value of the annotation can be the groupid:artifactidcom.example:foo, com.example:bar.
      @StubRunnerPort("foo")
 int fooPort;
 @StubRunnerPort("com.example:bar")
-int barPort;

    6.5 Stub Runner Spring Cloud

    Stub Runner can integrate with Spring Cloud.

    For real life examples you can check the

    6.5.1 Stubbing Service Discovery

    The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

    • DiscoveryClient
    • Ribbon ServerList

    that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. +int barPort;

    6.5 Stub Runner Spring Cloud

    Stub Runner can integrate with Spring Cloud.

    For real life examples you can check the

    6.5.1 Stubbing Service Discovery

    The most important feature of Stub Runner Spring Cloud is the fact that it’s stubbing

    • DiscoveryClient
    • Ribbon ServerList

    that means that regardless of the fact whether you’re using Zookeeper, Consul, Eureka or anything else, you don’t need that in your tests. We’re starting WireMock instances of your dependencies and we’re telling your application whenever you’re using Feign, load balanced RestTemplate or DiscoveryClient directly, to call those stubbed servers instead of calling the real Service Discovery tool.

    For example this test will pass

    def 'should make service discovery work'() {
 	expect: 'WireMocks are running'
@@ -6603,7 +6603,7 @@ inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
 properties
    Table 10.2. SCM Stub Downloader properties
    Name of a property
    Default
    Description
    * pactbroker.host (plugin prop)
    * stubrunner.properties.pactbroker.host (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)
    Host from URL passed to repositoryRoot
    What is the URL of Pact Broker
    * pactbroker.port (plugin prop)
    * stubrunner.properties.pactbroker.port (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop)
    Port from URL passed to repositoryRoot
    What is the port of Pact Broker
    * pactbroker.protocol (plugin prop)
    * stubrunner.properties.pactbroker.protocol (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop)
    Protocol from URL passed to repositoryRoot
    What is the protocol of Pact Broker
    * pactbroker.tags (plugin prop)
    * stubrunner.properties.pactbroker.tags (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop)
    Version of the stub, or latest if version is +
    What tags should be used to fetch the stub
    * pactbroker.auth.scheme (plugin prop)
    * stubrunner.properties.pactbroker.auth.scheme (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop)
    Basic
    What kind of authentication should be used to connect to the Pact Broker
    * pactbroker.auth.username (plugin prop)
    * stubrunner.properties.pactbroker.auth.username (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop)
    The username passed to contractsRepositoryUsername (maven) or contractRepository.username (gradle)
    Username used to connect to the Pact Broker
    * pactbroker.auth.password (plugin prop)
    * stubrunner.properties.pactbroker.auth.password (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)
    The password passed to contractsRepositoryPassword (maven) or contractRepository.password (gradle)
    Password used to connect to the Pact Broker
    * pactbroker.provider-name-with-group-id (plugin prop)
    * stubrunner.properties.pactbroker.provider-name-with-group-id (system prop)
    * STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop)
    false
    When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used

    11. Spring Cloud Contract WireMock

    The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the -samples +samples for more details.

    If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with spring-boot-starter-web), you can add spring-cloud-starter-contract-stub-runner to your classpath and add @AutoConfigureWireMock in diff --git a/2.1.x/spring-cloud-contract-maven-plugin/index.html b/2.1.x/spring-cloud-contract-maven-plugin/index.html index 9cf74b2ec3..6662663793 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/index.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/index.html @@ -361,10 +361,10 @@ examples of Maven plugin setup.

    diff --git a/2.1.x/spring-cloud-contract-maven-plugin/junit.html b/2.1.x/spring-cloud-contract-maven-plugin/junit.html index c0fc751141..f9b3a9ca0e 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/junit.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/junit.html @@ -326,7 +326,7 @@

    Project source code

    -

    https://github.com/spring-cloud/spring-cloud-contract/tree/master/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/spring-boot-java

    +

    https://github.com/spring-cloud/spring-cloud-contract/tree/2.1.x/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/spring-boot-java

    diff --git a/2.1.x/spring-cloud-contract-maven-plugin/spock.html b/2.1.x/spring-cloud-contract-maven-plugin/spock.html index ca2eef1ca2..4499752e3a 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/spock.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/spock.html @@ -371,7 +371,7 @@

    Project source code

    -

    https://github.com/spring-cloud/spring-cloud-contract/tree/master/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/spring-boot-groovy

    +

    https://github.com/spring-cloud/spring-cloud-contract/tree/2.1.x/spring-cloud-contract-tools/spring-cloud-contract-maven-plugin/src/test/projects/spring-boot-groovy

    diff --git a/2.1.x/spring-cloud-contract.xml b/2.1.x/spring-cloud-contract.xml index 5ea8c70bd7..d1106df93a 100644 --- a/2.1.x/spring-cloud-contract.xml +++ b/2.1.x/spring-cloud-contract.xml @@ -56,7 +56,7 @@ from (Codearte. - + Microservices Architecture @@ -131,7 +131,7 @@ are those that your application directly uses. - + Stubbed Services @@ -748,8 +748,8 @@ we mark the client as a fraud. Issuance has an artifact-id of http-client, and both have a group-id of com.example. Social remark - both client and server development teams need to communicate directly and discuss changes while going through the process. CDC is all about communication. -The server -side code is available here and the +The server +side code is available here and the client code here. In this case, the producer owns the contracts. Physically, all the contract are @@ -1588,7 +1588,7 @@ consumer you will break with your local changes. Repo structure Let’s assume that we have a producer with coordinates com.example:server and 3 consumers: client1, client2, client3. Then in the repository with common contracts you would have the following setup -(which you can checkout here): +(which you can checkout here): ├── com │   └── example │   └── server @@ -1626,15 +1626,15 @@ one to one to the contents of the repo. <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.2.0.BUILD-SNAPSHOT</version> + <version>2.1.3.RELEASE</version> <relativePath/> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> - <spring-cloud-contract.version>2.2.0.BUILD-SNAPSHOT</spring-cloud-contract.version> - <spring-cloud-release.version>Hoxton.BUILD-SNAPSHOT + <spring-cloud-contract.version>2.1.2.BUILD-SNAPSHOT</spring-cloud-contract.version> + <spring-cloud-release.version>Greenwich.BUILD-SNAPSHOT </spring-cloud-release.version> <excludeBuildFolders>true</excludeBuildFolders> </properties> @@ -3521,7 +3521,7 @@ or an environment variable. - + STS Exception @@ -4592,8 +4592,8 @@ producer stubs.       └── nested       └── contract3.groovy To achieve proper stub packaging. -Or using the Maven assembly plugin or -Gradle Jar task you have to create the following +Or using the Maven assembly plugin or +Gradle Jar task you have to create the following structure in your stubs jar. └── META-INF └── com.example @@ -5136,10 +5136,10 @@ int barPort; For real life examples you can check the -producer app sample +producer app sample -consumer app sample +consumer app sample
    @@ -10346,7 +10346,7 @@ properties Spring Cloud Contract WireMock The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the -samples +samples for more details. If you have a Spring Boot application that uses Tomcat as an embedded server (which is the default with spring-boot-starter-web), you can add