Wording changes (#1442)

Replacing some terms

docs/src/main/asciidoc/_project-features-contract.adoc

@@ -1004,7 +1004,7 @@ include::{plugins_path}/spring-cloud-contract-converters/src/test/groovy/org/spr
 ----
 
 [[contract-dsl-custom-methods]]
-==== Executing Custom Methods on the Server Side
+==== Calling Custom Methods on the Server Side
 
 IMPORTANT: This section is valid only for Groovy DSL. Check out the
 <<contract-dsl-matchers>> section for YAML examples of a similar feature.
@@ -1921,8 +1921,8 @@ your tests far more meaningful.
 Stateful contracts (known also as scenarios) are contract definitions that should be read
 in order. This might be useful in the following situations:
 
-* You want to execute the contract in a precisely defined order, since you use Spring
-Cloud Contract to test your stateful application
+* You want to invoke the contract in a precisely defined order, since you use Spring
+Cloud Contract to test your stateful application.
 
 TIP: We really discourage you from doing that, since contract tests should be stateless.
 
@@ -1952,4 +1952,4 @@ name of `scenario1` and the three following steps:
 . logout, marked as `Step2` (which closes the scenario).
 
 You can find more details about WireMock scenarios at
-https://wiremock.org/docs/stateful-behaviour/[https://wiremock.org/docs/stateful-behaviour/].
+https://wiremock.org/docs/stateful-behaviour/[https://wiremock.org/docs/stateful-behaviour/].

docs/src/main/asciidoc/_project-features-messaging.adoc

@@ -38,7 +38,7 @@ include::{verifier_core_path}/src/test/resources/yml/contract_message_method.yml
 ====
 
 In the previous example case, the output message is sent to `output` if a method called
-`bookReturnedTriggered` is executed. On the message publisher's side, we generate a
+`bookReturnedTriggered` is invoked. On the message publisher's side, we generate a
 test that calls that method to trigger the message. On the consumer side, you can use
 the `some_label` to trigger the message.
 

docs/src/main/asciidoc/_project-features-stubrunner.adoc

@@ -380,7 +380,7 @@ include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contra
 
 A `StubRunnerExtension` is also available for JUnit 5. `StubRunnerRule` and
 `StubRunnerExtension` work in a very similar fashion. After the rule or extension is
-executed, Stub Runner connects to your Maven repository and, for the given list of
+called, Stub Runner connects to your Maven repository and, for the given list of
 dependencies, tries to:
 
 - Download them
@@ -719,7 +719,7 @@ include::{stubrunner_core_path}/src/test/groovy/org/springframework/cloud/contra
 
 One way to use Stub Runner Boot is to use it as a feed of stubs for "`smoke tests`". What does that mean?
 Assume that you do not want to deploy 50 microservices to a test environment in order
-to see whether your application works. You have already executed a suite of tests during the build process,
+to see whether your application works. You have already run a suite of tests during the build process,
 but you would also like to ensure that the packaging of your application works. You can
 deploy your application to an environment, start it, and run a couple of tests on it to see whether
 it works. We can call those tests "`smoke tests`", because their purpose is to check only a handful

docs/src/main/asciidoc/docker-project.adoc

@@ -110,7 +110,7 @@ from the container's `.m2`. Mount your local `.m2` as a volume available at the
 
 WARNING: You must not set both `EXTERNAL_CONTRACTS_WORK_OFFLINE` and `EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL`.
 
-The following environment variables are used when tests are executed:
+The following environment variables are used when tests are run:
 
 - `APPLICATION_BASE_URL`: URL against which tests should be run.
 Remember that it has to be accessible from the Docker container (for example, `localhost`
@@ -168,7 +168,7 @@ $ CURRENT_DIR="$( pwd )"
 $ CURRENT_FOLDER_NAME=${PWD##*/}
 $ PROJECT_VERSION="0.0.1.RELEASE"
 
-# Execute contract tests
+# Run contract tests
 $ docker run  --rm -e "APPLICATION_BASE_URL=${APPLICATION_BASE_URL}" -e "PUBLISH_ARTIFACTS=true" -e "PROJECT_NAME=${CURRENT_FOLDER_NAME}" -e "REPO_WITH_BINARIES_URL=${ARTIFACTORY_URL}" -e "PROJECT_VERSION=${PROJECT_VERSION}" -v "${CURRENT_DIR}/contracts/:/contracts:ro" -v "${CURRENT_DIR}/node_modules/spring-cloud-contract/output:/spring-cloud-contract-output/" springcloud/spring-cloud-contract:"${SC_CONTRACT_DOCKER_VERSION}"
 
 # Kill app
@@ -190,7 +190,7 @@ stateful situation.
 - The contract tests are generated through Docker, and tests
 are run against the running application.
 ** The contracts are taken from `/contracts` folder.
-** The output of the test execution is available under
+** The output of the test is available under
 `node_modules/spring-cloud-contract/output`.
 - The stubs are uploaded to Artifactory. You can find them in
 http://localhost:8081/artifactory/libs-release-local/com/example/bookstore/0.0.1.RELEASE/ .
@@ -263,7 +263,7 @@ that the stubs are setup properly. To do so, run the following commands:
 ====
 [source,bash]
 ----
-# let's execute the first request (no response is returned)
+# let's run the first request (no response is returned)
 $ curl -H "Content-Type:application/json" -X POST --data '{ "title" : "Title", "genre" : "Genre", "description" : "Description", "author" : "Author", "publisher" : "Publisher", "pages" : 100, "image_url" : "https://d213dhlpdb53mu.cloudfront.net/assets/pivotal-square-logo-41418bd391196c3022f3cd9f3959b3f6d7764c47873d858583384e759c7db435.svg", "buy_url" : "https://pivotal.io" }' http://localhost:9876/api/books
 # Now time for the second request
 $ curl -X GET http://localhost:9876/api/books

docs/src/main/asciidoc/getting-started.adoc

@@ -1044,7 +1044,7 @@ from the provided contracts:
 - Produce and install stubs
 
 You do not want to generate tests, since you, as the consumer, want only to play with the
-stubs. You need to skip the test generation and execution. To do so, run the following commands:
+stubs. You need to skip the test generation and invokation. To do so, run the following commands:
 
 ====
 [source,bash,indent=0]

docs/src/main/asciidoc/ghpages.sh

@@ -4,7 +4,7 @@ set -e
 
 # Set default props like MAVEN_PATH, ROOT_FOLDER etc.
 function set_default_props() {
-    # The script should be executed from the root folder
+    # The script should be run from the root folder
     ROOT_FOLDER=`pwd`
     echo "Current folder is ${ROOT_FOLDER}"
 
@@ -65,7 +65,7 @@ function build_docs_if_applicable() {
 }
 
 # Get the name of the `docs.main` property
-# Get whitelisted branches - assumes that a `docs` module is available under `docs` profile
+# Get allowed branches - assumes that a `docs` module is available under `docs` profile
 function retrieve_doc_properties() {
     MAIN_ADOC_VALUE=$("${MAVEN_PATH}"mvn -q \
         -Dexec.executable="echo" \
@@ -75,14 +75,14 @@ function retrieve_doc_properties() {
     echo "Extracted 'main.adoc' from Maven build [${MAIN_ADOC_VALUE}]"
 
 
-    WHITELIST_PROPERTY=${WHITELIST_PROPERTY:-"docs.whitelisted.branches"}
-    WHITELISTED_BRANCHES_VALUE=$("${MAVEN_PATH}"mvn -q \
+    ALLOW_PROPERTY=${ALLOW_PROPERTY:-"docs.allowed.branches"}
+    ALLOWED_BRANCHES_VALUE=$("${MAVEN_PATH}"mvn -q \
         -Dexec.executable="echo" \
-        -Dexec.args="\${${WHITELIST_PROPERTY}}" \
+        -Dexec.args="\${${ALLOW_PROPERTY}}" \
         org.codehaus.mojo:exec-maven-plugin:1.3.1:exec \
         -P docs \
         -pl docs)
-    echo "Extracted '${WHITELIST_PROPERTY}' from Maven build [${WHITELISTED_BRANCHES_VALUE}]"
+    echo "Extracted '${ALLOW_PROPERTY}' from Maven build [${ALLOWED_BRANCHES_VALUE}]"
 }
 
 # Stash any outstanding changes
@@ -148,9 +148,9 @@ function copy_docs_for_current_version() {
     else
         echo -e "Current branch is [${CURRENT_BRANCH}]"
         # https://stackoverflow.com/questions/29300806/a-bash-script-to-check-if-a-string-is-present-in-a-comma-separated-list-of-strin
-        if [[ ",${WHITELISTED_BRANCHES_VALUE}," = *",${CURRENT_BRANCH},"* ]] ; then
+        if [[ ",${ALLOWED_BRANCHES_VALUE}," = *",${CURRENT_BRANCH},"* ]] ; then
             mkdir -p ${ROOT_FOLDER}/${CURRENT_BRANCH}
-            echo -e "Branch [${CURRENT_BRANCH}] is whitelisted! Will copy the current docs to the [${CURRENT_BRANCH}] folder"
+            echo -e "Branch [${CURRENT_BRANCH}] is allowed! Will copy the current docs to the [${CURRENT_BRANCH}] folder"
             for f in docs/target/generated-docs/*; do
                 file=${f#docs/target/generated-docs/*}
                 if ! git ls-files -i -o --exclude-standard --directory | grep -q ^$file$; then
@@ -169,7 +169,7 @@ function copy_docs_for_current_version() {
             done
             COMMIT_CHANGES="yes"
         else
-            echo -e "Branch [${CURRENT_BRANCH}] is not on the white list! Check out the Maven [${WHITELIST_PROPERTY}] property in
+            echo -e "Branch [${CURRENT_BRANCH}] is not on the allow list! Check out the Maven [${ALLOW_PROPERTY}] property in
              [docs] module available under [docs] profile. Won't commit any changes to gh-pages for this branch."
         fi
     fi
@@ -250,10 +250,10 @@ the script will work in the following manner:
 
 - if there's no gh-pages / target for docs module then the script ends
 - for master branch the generated docs are copied to the root of gh-pages branch
-- for any other branch (if that branch is whitelisted) a subfolder with branch name is created
+- for any other branch (if that branch is allowed) a subfolder with branch name is created
     and docs are copied there
 - if the version switch is passed (-v) then a tag with (v) prefix will be retrieved and a folder
-    with that version number will be created in the gh-pages branch. WARNING! No whitelist verification will take place
+    with that version number will be created in the gh-pages branch. WARNING! No allow verification will take place
 - if the destination switch is passed (-d) then the script will check if the provided dir is a git repo and then will
     switch to gh-pages of that repo and copy the generated docs to `docs/<project-name>/<version>`
 - if the destination switch is passed (-d) then the script will check if the provided dir is a git repo and then will
@@ -327,4 +327,4 @@ build_docs_if_applicable
 retrieve_doc_properties
 stash_changes
 add_docs_from_target
-checkout_previous_branch
+checkout_previous_branch

docs/src/main/asciidoc/gradle-project.adoc

@@ -345,7 +345,7 @@ JAR is available offline, remotely, and so on).
 * `deleteStubsAfterTest`: If set to `false`, do not remove any downloaded
 contracts from temporary directories.
 * `failOnNoContracts`: When enabled, will throw an exception when no contracts were found. Defaults to `true`.
-* `failOnInProgress`: If set to true then if any contracts that are in progress are found, will break the build. On the producer side you need to be explicit about the fact that you have contracts in progress and take into consideration that you might be causing false positive test execution results on the consumer side.. Defaults to `true`.
+* `failOnInProgress`: If set to `true`, then, if any contracts that are in progress are found, they break the build. On the producer side, you need to be explicit about the fact that you have contracts in progress and take into consideration that you might be causing false positive test results on the consumer side. Defaults to `true`.
 
 There is also the `contractRepository { ... }` closure that contains the following properties
 

docs/src/main/asciidoc/howto.adoc

@@ -645,7 +645,7 @@ to use the SCM implementation from the URL that starts with
 the `git://` protocol.
 
 IMPORTANT: You have to manually add the `pushStubsToScm`
-goal in Maven or execute (bind) the `pushStubsToScm` task in
+goal in Maven or use (bind) the `pushStubsToScm` task in
 Gradle. We do not push stubs to the `origin` of your git
 repository.
 
@@ -714,7 +714,7 @@ contracts {
 
 /*
 In this scenario we want to publish stubs to SCM whenever
-the `publish` task is executed
+the `publish` task is invoked
 */
 publish.dependsOn("publishStubsToScm")
 ----
@@ -902,7 +902,7 @@ include::{standalone_pact_path}/http-server/build.gradle[tags=pact_dependency,in
 ----
 ====
 
-When you execute the build of your application, a test and stub is generated. The following
+When you build your application, a test and stub is generated. The following
 example shows a test and stub that came from this process:
 
 ====
@@ -1312,14 +1312,14 @@ If you use YAML, you can use the `bodyFromFile` property.
 
 Spring Cloud Contract comes with a `ToFileContractsTransformer` class that lets you dump
 contracts as files for the given `ContractConverter`. It contains a `static void main`
-method that lets you execute the transformer as an executable. It takes the following
+method that lets you invoke the transformer as an executable. It takes the following
 arguments:
 
 - argument 1 : `FQN`: Fully qualified name of the `ContractConverter` (for example, `PactContractConverter`). *REQUIRED*.
 - argument 2 : `path`: Path where the dumped files should be stored. *OPTIONAL* -- defaults to `target/converted-contracts`.
 - argument 3 : `path`: Path were the contracts should be searched for. *OPTIONAL* -- defaults to `src/test/resources/contracts`.
 
-After executing the transformer, the Spring Cloud Contract files are processed and,
+After calling the transformer, the Spring Cloud Contract files are processed and,
 depending on the provided FQN of the `ContractTransformer`, the contracts are transformed
 to the required format and dumped to the provided folder.
 

docs/src/main/asciidoc/maven-project.adoc

@@ -252,7 +252,7 @@ extends `com.example.base.BaseClass`. This setting takes precedence over
 * `contractsProperties`: A map that contains properties to be passed to Spring Cloud Contract
 components. Those properties might be used by (for example) built-in or custom Stub Downloaders.
 * `failOnNoContracts`: When enabled, will throw an exception when no contracts were found. Defaults to `true`.
-* `failOnInProgress`: If set to true then if any contracts that are in progress are found, will break the build. On the producer side you need to be explicit about the fact that you have contracts in progress and take into consideration that you might be causing false positive test execution results on the consumer side.. Defaults to `true`.
+* `failOnInProgress`: If set to `true`, then, if any contracts that are in progress are found, they break the build. On the producer side, you need to be explicit about the fact that you have contracts in progress and take into consideration that you might be causing false positive test results on the consumer side. Defaults to `true`.
 * `incrementalContractTests`: When enabled, tests are created only when contracts have changed since last build. Defaults to `true`.
 * `incrementalContractStubs`: When enabled, stubs are created only when contracts have changed since last build. Defaults to `true`.
 * `incrementalContractStubsJar`: When enabled, stubs jar is created only when stubs have changed since last build. Defaults to `true`.
@@ -581,7 +581,7 @@ In order to fix this issue, provide the following section in your `pom.xml`:
 
 You can select the http://spockframework.org/[Spock Framework] for creating and running the auto-generated contract
 verification tests with both Maven and Gradle. However, whereas using Gradle is straightforward,
-in Maven, you will require some additional setup in order to make the tests compile and execute properly.
+in Maven, you will require some additional setup in order to make the tests compile and work properly.
 
 First of all, you must use a plugin, such as the https://github.com/groovy/GMavenPlus[GMavenPlus] plugin,
 to add Groovy to your project. In GMavenPlus plugin, you need to explicitly set test sources, including both the

docs/src/main/asciidoc/project-features.adoc

@@ -21,7 +21,7 @@ include::_project-features-wiremock.adoc[]
 [[features-build-tools]]
 == Build Tools Integration
 
-You can run test generation and stub execution in various ways. The most common ones are
+You can run test generation and stub invokation in various ways. The most common ones are
 as follows:
 
 * link:maven-project.html[Maven]

docs/src/main/asciidoc/using.adoc

@@ -169,7 +169,7 @@ contracts {
 
 /*
 In this scenario we want to publish stubs to SCM whenever
-the `publish` task is executed
+the `publish` task is run
 */
 publish.dependsOn("publishStubsToScm")
 ----