From 678274c8721f64a438944b677b412fee3d969079 Mon Sep 17 00:00:00 2001 From: Jay Bryant Date: Tue, 14 Jul 2020 04:47:44 -0500 Subject: [PATCH] Wording changes (#1442) Replacing some terms --- .../asciidoc/_project-features-contract.adoc | 8 +++---- .../asciidoc/_project-features-messaging.adoc | 2 +- .../_project-features-stubrunner.adoc | 4 ++-- docs/src/main/asciidoc/docker-project.adoc | 8 +++---- docs/src/main/asciidoc/getting-started.adoc | 2 +- docs/src/main/asciidoc/ghpages.sh | 24 +++++++++---------- docs/src/main/asciidoc/gradle-project.adoc | 2 +- docs/src/main/asciidoc/howto.adoc | 10 ++++---- docs/src/main/asciidoc/maven-project.adoc | 4 ++-- docs/src/main/asciidoc/project-features.adoc | 2 +- docs/src/main/asciidoc/using.adoc | 2 +- 11 files changed, 34 insertions(+), 34 deletions(-) diff --git a/docs/src/main/asciidoc/_project-features-contract.adoc b/docs/src/main/asciidoc/_project-features-contract.adoc index 85daf731d5..ec2049d2ef 100644 --- a/docs/src/main/asciidoc/_project-features-contract.adoc +++ b/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 <> 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/]. \ No newline at end of file +https://wiremock.org/docs/stateful-behaviour/[https://wiremock.org/docs/stateful-behaviour/]. diff --git a/docs/src/main/asciidoc/_project-features-messaging.adoc b/docs/src/main/asciidoc/_project-features-messaging.adoc index 86ebdc2f34..5948911ba7 100644 --- a/docs/src/main/asciidoc/_project-features-messaging.adoc +++ b/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. diff --git a/docs/src/main/asciidoc/_project-features-stubrunner.adoc b/docs/src/main/asciidoc/_project-features-stubrunner.adoc index ae3e5a5a13..7bd919104a 100644 --- a/docs/src/main/asciidoc/_project-features-stubrunner.adoc +++ b/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 diff --git a/docs/src/main/asciidoc/docker-project.adoc b/docs/src/main/asciidoc/docker-project.adoc index 3f6f998e1d..b32721130d 100644 --- a/docs/src/main/asciidoc/docker-project.adoc +++ b/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 diff --git a/docs/src/main/asciidoc/getting-started.adoc b/docs/src/main/asciidoc/getting-started.adoc index 7d0faf0152..cfc0b8e183 100644 --- a/docs/src/main/asciidoc/getting-started.adoc +++ b/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] diff --git a/docs/src/main/asciidoc/ghpages.sh b/docs/src/main/asciidoc/ghpages.sh index 55e76be191..d18aa88d3c 100755 --- a/docs/src/main/asciidoc/ghpages.sh +++ b/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//` - 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 \ No newline at end of file +checkout_previous_branch diff --git a/docs/src/main/asciidoc/gradle-project.adoc b/docs/src/main/asciidoc/gradle-project.adoc index ab32951619..b6baef92a6 100644 --- a/docs/src/main/asciidoc/gradle-project.adoc +++ b/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 diff --git a/docs/src/main/asciidoc/howto.adoc b/docs/src/main/asciidoc/howto.adoc index befbca9f71..b6a90f9845 100644 --- a/docs/src/main/asciidoc/howto.adoc +++ b/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. diff --git a/docs/src/main/asciidoc/maven-project.adoc b/docs/src/main/asciidoc/maven-project.adoc index d49e35dea4..f45061b6c3 100644 --- a/docs/src/main/asciidoc/maven-project.adoc +++ b/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 diff --git a/docs/src/main/asciidoc/project-features.adoc b/docs/src/main/asciidoc/project-features.adoc index 6b30c36718..a8f7963fcf 100644 --- a/docs/src/main/asciidoc/project-features.adoc +++ b/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] diff --git a/docs/src/main/asciidoc/using.adoc b/docs/src/main/asciidoc/using.adoc index 1d2c65a77c..904a0e3829 100644 --- a/docs/src/main/asciidoc/using.adoc +++ b/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") ----