Removed reference in the docs to samples

Author: marcingrzejszczak

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:
 

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.
 

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

docs/modules/ROOT/pages/getting-started/cdc.adoc

@@ -24,34 +24,15 @@ 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.
 
 [[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.
 

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

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[]
-----
-======
-////
-
-////
-[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/fraud/shouldMarkClientAsFraud.groovy[Click here to see the Groovy Code]
+
+{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.