From 877056115c8a3b250cc1c9ce38cfcb45b1d3fc59 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 18 Mar 2019 14:47:01 +0000 Subject: [PATCH] Sync docs from 1.2.x to gh-pages --- .../multi__spring_cloud_contract_faq.html | 4 ++-- ...ti__spring_cloud_contract_stub_runner.html | 6 ++--- ..._cloud_contract_verifier_introduction.html | 6 ++--- ..._spring_cloud_contract_verifier_setup.html | 6 ++--- 1.2.x/single/spring-cloud-contract.html | 22 +++++++++---------- 1.2.x/spring-cloud-contract.xml | 22 +++++++++---------- 6 files changed, 33 insertions(+), 33 deletions(-) diff --git a/1.2.x/multi/multi__spring_cloud_contract_faq.html b/1.2.x/multi/multi__spring_cloud_contract_faq.html index 0e0b30661b..e603c5a6e9 100644 --- a/1.2.x/multi/multi__spring_cloud_contract_faq.html +++ b/1.2.x/multi/multi__spring_cloud_contract_faq.html @@ -102,7 +102,7 @@ expectations of the 3 consumers (client1,

Example of a pom.xml inside the server folder.

<?xml version="1.0" encoding="UTF-8"?>
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 	<modelVersion>4.0.0</modelVersion>
 
 	<groupId>com.example</groupId>
@@ -211,7 +211,7 @@ one to one to the contents of the repo.

Example of a mvn clean install -DskipTests to locally install stubs of the producer project.

The pom.xml in the root folder can look like this:

<?xml version="1.0" encoding="UTF-8"?>
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 	<modelVersion>4.0.0</modelVersion>
 
 	<groupId>com.example.standalone</groupId>
diff --git a/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html b/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html
index b32aea86d8..04c32d0184 100644
--- a/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html
+++ b/1.2.x/multi/multi__spring_cloud_contract_stub_runner.html
@@ -63,9 +63,9 @@ versions, which are automatically uploaded after every successful build:

"http://repo.spring.io/snapshot" } - maven { url "http://repo.spring.io/milestone" } - maven { url "http://repo.spring.io/release" } + maven { url "https://repo.spring.io/snapshot" } + maven { url "https://repo.spring.io/milestone" } + maven { url "https://repo.spring.io/release" } }

6.2 Publishing Stubs as JARs

The easiest approach would be to centralize the way stubs are kept. For example, you can keep them as jars in a Maven repository.

[Tip]Tip

For both Maven and Gradle, the setup comes ready to work. However, you can customize diff --git a/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html index e97d138b60..24d31f89ea 100644 --- a/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html +++ b/1.2.x/multi/multi__spring_cloud_contract_verifier_introduction.html @@ -236,9 +236,9 @@ following section to your build:

Maven. 

repositories {
 	mavenCentral()
 	mavenLocal()
-	maven { url "http://repo.spring.io/snapshot" }
-	maven { url "http://repo.spring.io/milestone" }
-	maven { url "http://repo.spring.io/release" }
+	maven { url "https://repo.spring.io/snapshot" }
+	maven { url "https://repo.spring.io/milestone" }
+	maven { url "https://repo.spring.io/release" }
 }

2.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
diff --git a/1.2.x/multi/multi__spring_cloud_contract_verifier_setup.html b/1.2.x/multi/multi__spring_cloud_contract_verifier_setup.html
index 7153cbeda4..abf8cae007 100644
--- a/1.2.x/multi/multi__spring_cloud_contract_verifier_setup.html
+++ b/1.2.x/multi/multi__spring_cloud_contract_verifier_setup.html
@@ -53,9 +53,9 @@ which are automatically uploaded after every successful build, as shown here:

"http://repo.spring.io/snapshot" } - maven { url "http://repo.spring.io/milestone" } - maven { url "http://repo.spring.io/release" } + maven { url "https://repo.spring.io/snapshot" } + maven { url "https://repo.spring.io/milestone" } + maven { url "https://repo.spring.io/release" } } }

4.1.5 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory.

The directory containing stub definitions is treated as a class name, and each stub diff --git a/1.2.x/single/spring-cloud-contract.html b/1.2.x/single/spring-cloud-contract.html index 88b02bebd9..ac1dea2858 100644 --- a/1.2.x/single/spring-cloud-contract.html +++ b/1.2.x/single/spring-cloud-contract.html @@ -241,9 +241,9 @@ following section to your build:

Maven. 

repositories {
 	mavenCentral()
 	mavenLocal()
-	maven { url "http://repo.spring.io/snapshot" }
-	maven { url "http://repo.spring.io/milestone" }
-	maven { url "http://repo.spring.io/release" }
+	maven { url "https://repo.spring.io/snapshot" }
+	maven { url "https://repo.spring.io/milestone" }
+	maven { url "https://repo.spring.io/release" }
 }

2.4.2 Consumer side (Loan Issuance)

As a developer of the Loan Issuance service (a consumer of the Fraud Detection server), you might do the following steps:

  1. Start doing TDD by writing a test for your feature.
  2. Write the missing implementation.
  3. Clone the Fraud Detection service repository locally.
  4. Define the contract locally in the repo of Fraud Detection service.
  5. Add the Spring Cloud Contract Verifier plugin.
  6. Run the integration tests.
  7. File a pull request.
  8. Create an initial implementation.
  9. Take over the pull request.
  10. Write the missing implementation.
  11. Deploy your app.
  12. Work online.

Start doing TDD by writing a test for your feature.

@Test
 public void shouldBeRejectedDueToAbnormalLoanAmount() {
@@ -663,7 +663,7 @@ expectations of the 3 consumers (client1, 

Example of a pom.xml inside the server folder.

<?xml version="1.0" encoding="UTF-8"?>
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 	<modelVersion>4.0.0</modelVersion>
 
 	<groupId>com.example</groupId>
@@ -772,7 +772,7 @@ one to one to the contents of the repo.

Example of a mvn clean install -DskipTests to locally install stubs of the producer project.

The pom.xml in the root folder can look like this:

<?xml version="1.0" encoding="UTF-8"?>
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
+		 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
 	<modelVersion>4.0.0</modelVersion>
 
 	<groupId>com.example.standalone</groupId>
@@ -913,9 +913,9 @@ which are automatically uploaded after every successful build, as shown here:

"http://repo.spring.io/snapshot" } - maven { url "http://repo.spring.io/milestone" } - maven { url "http://repo.spring.io/release" } + maven { url "https://repo.spring.io/snapshot" } + maven { url "https://repo.spring.io/milestone" } + maven { url "https://repo.spring.io/release" } } }

4.1.5 Add stubs

By default, Spring Cloud Contract Verifier is looking for stubs in the src/test/resources/contracts directory.

The directory containing stub definitions is treated as a class name, and each stub @@ -1785,9 +1785,9 @@ versions, which are automatically uploaded after every successful build:

"http://repo.spring.io/snapshot" } - maven { url "http://repo.spring.io/milestone" } - maven { url "http://repo.spring.io/release" } + maven { url "https://repo.spring.io/snapshot" } + maven { url "https://repo.spring.io/milestone" } + maven { url "https://repo.spring.io/release" } }

6.2 Publishing Stubs as JARs

The easiest approach would be to centralize the way stubs are kept. For example, you can keep them as jars in a Maven repository.

[Tip]Tip

For both Maven and Gradle, the setup comes ready to work. However, you can customize diff --git a/1.2.x/spring-cloud-contract.xml b/1.2.x/spring-cloud-contract.xml index a3a0c3763d..973503b115 100644 --- a/1.2.x/spring-cloud-contract.xml +++ b/1.2.x/spring-cloud-contract.xml @@ -429,9 +429,9 @@ following section to your build: repositories { mavenCentral() mavenLocal() - maven { url "http://repo.spring.io/snapshot" } - maven { url "http://repo.spring.io/milestone" } - maven { url "http://repo.spring.io/release" } + maven { url "https://repo.spring.io/snapshot" } + maven { url "https://repo.spring.io/milestone" } + maven { url "https://repo.spring.io/release" } } @@ -1179,7 +1179,7 @@ one to one to the contents of the repo. Example of a pom.xml inside the server folder. <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> @@ -1291,7 +1291,7 @@ Those poms are necessary for the consumer side to run mvn clean install The pom.xml in the root folder can look like this: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.example.standalone</groupId> @@ -1559,9 +1559,9 @@ which are automatically uploaded after every successful build, as shown here: @@ -3095,9 +3095,9 @@ versions, which are automatically uploaded after every successful build: