rename WDT (#880)

Author: rosemarymarano

CONTRIBUTING.md

@@ -5,7 +5,7 @@ If you want to submit a pull request to fix a bug or enhance an existing feature
 
 If you have any questions about a possible submission, feel free to open an issue too.
 
-## [Contributing to the Oracle WLS Deploy repository](http://github.com/oracle/wls-deploy/blob/master/CONTRIBUTING.md)
+## [Contributing to the WebLogic Deploy repository](http://github.com/oracle/wls-deploy/blob/master/CONTRIBUTING.md)
 Pull requests can be made under [The Oracle Contributor Agreement](https://www.oracle.com/technetwork/community/oca-486395.html) (OCA).
 
 For pull requests to be accepted, the bottom of your commit message must have the following line using your name and e-mail address as it appears in the OCA Signatories list.

KnownIssues.md

@@ -1,4 +1,4 @@
-## Known Issues for Oracle WebLogic Server Deploy Tooling
+## Known Issues for WebLogic Deploy Tooling
 
 The following list contains known issues. Each issue may contain a workaround or an associated issue number.
 

README.md

@@ -1,8 +1,8 @@
-# Oracle WebLogic Server Deploy Tooling
+# WebLogic Deploy Tooling
 
-Many organizations are using WebLogic Server, with or without other Oracle Fusion Middleware components, to run their enterprise applications.  As more and more organizations move toward Continuous Delivery of their applications, the importance of automated testing grows.  Automating WebLogic Server domain creation and application deployment with hand-coded WLST scripts is challenging.  After those scripts exist for a project, they must be maintained as the project evolves.  The motivation for the Oracle WebLogic Server Deploy Tooling project is to remove the need for most users to write WLST scripts for routine domain creation and application deployment tasks.  Instead, the project team can write a declarative, metadata model describing the domain and applications (with their dependent resources), and use one or more of the single-purpose tools provided that perform domain lifecycle operations based on the content of the model.  The goal is to make it easy to stand up environments and perform domain lifecycle operations in a repeatable fashion based on a metadata model that can be treated as source and evolve as the project evolves.
+Many organizations are using WebLogic Server, with or without other Oracle Fusion Middleware components, to run their enterprise applications.  As more and more organizations move toward Continuous Delivery of their applications, the importance of automated testing grows.  Automating WebLogic Server domain creation and application deployment with hand-coded WLST scripts is challenging.  After those scripts exist for a project, they must be maintained as the project evolves.  The motivation for the WebLogic Deploy Tooling project is to remove the need for most users to write WLST scripts for routine domain creation and application deployment tasks.  Instead, the project team can write a declarative, metadata model describing the domain and applications (with their dependent resources), and use one or more of the single-purpose tools provided that perform domain lifecycle operations based on the content of the model.  The goal is to make it easy to stand up environments and perform domain lifecycle operations in a repeatable fashion based on a metadata model that can be treated as source and evolve as the project evolves.
 
-## Features of the Oracle WebLogic Server Deploy Tooling
+## Features of the WebLogic Deploy Tooling
 
 Currently, the project provides several single-purpose tools, all exposed as shell scripts (both Windows and UNIX scripts are provided):
 
@@ -13,8 +13,8 @@ Currently, the project provides several single-purpose tools, all exposed as she
 - The [Encrypt Model Tool](site/encrypt.md) (`encryptModel`) encrypts the passwords in a model (or its variable file) using a user-provided passphrase.
 - The [Validate Model Tool](site/validate.md) (`validateModel`) provides both standalone validation of a model as well as model usage information to help users write or edit their models.
 - The [Compare Model Tool](site/compare.md) (`compareModel`) compares two model files.
-- The [Prepare Model Tool](site/prepare.md) (`prepareModel`) prepares model files for deploying to WebLogic Server Kubernetes Operator environment.
-- The [Extract Domain Resource Tool](site/kubernetes.md) (`extractDomainResource`) generates a domain resource YAML for use with the Oracle WebLogic Server Kubernetes Operator.
+- The [Prepare Model Tool](site/prepare.md) (`prepareModel`) prepares model files for deploying to WebLogic Kubernetes Operator environment.
+- The [Extract Domain Resource Tool](site/kubernetes.md) (`extractDomainResource`) generates a domain resource YAML for use with the WebLogic Kubernetes Operator.
 - The [Variable Injector Tool](site/variable_injection.md) is used to tokenize a model with variables.
 - The [Model Help Tool](site/model_help.md) (`modelHelp.sh`) provides information about the folders and attributes that are valid for sections and folders of a domain model.
 
@@ -23,12 +23,12 @@ As new use cases are discovered, new tools will likely be added to cover those o
 
 ## Downloading and Installing the Software
 
-The Oracle WebLogic Server Deploy Tooling project repository is located at [`https://github.com/oracle/weblogic-deploy-tooling`](https://github.com/oracle/weblogic-deploy-tooling).  Binary distributions of the `weblogic-deploy.zip` installer can be downloaded from the [GitHub Releases page](https://github.com/oracle/weblogic-deploy-tooling/releases).  To install the software, simply unzip the `weblogic-deploy.zip` installer on a machine that has the desired versions of WebLogic Server installed.  After being unzipped, the software is ready to use, just set the `JAVA_HOME` environment variable to point to a Java 7 or higher JDK  and the shell scripts are ready to run.
+The WebLogic Deploy Tooling project repository is located at [`https://github.com/oracle/weblogic-deploy-tooling`](https://github.com/oracle/weblogic-deploy-tooling).  Binary distributions of the `weblogic-deploy.zip` installer can be downloaded from the [GitHub Releases page](https://github.com/oracle/weblogic-deploy-tooling/releases).  To install the software, simply unzip the `weblogic-deploy.zip` installer on a machine that has the desired versions of WebLogic Server installed.  After being unzipped, the software is ready to use, just set the `JAVA_HOME` environment variable to point to a Java 7 or higher JDK  and the shell scripts are ready to run.
 
 
 ## Supported WLS Versions
 
-For the supported WebLogic Server and JDK versions required to run WebLogic Server Deploy Tooling, see [Supported WLS Versions](site/wls_versions.md).
+For the supported WebLogic Server and JDK versions required to run WebLogic Deploy Tooling, see [Supported WLS Versions](site/wls_versions.md).
 
 
 ## Concepts

samples/docker-domain/README.md

@@ -2,7 +2,7 @@ Example Image with a WLS Domain
 ===============================
 This Dockerfile extends the Oracle WebLogic Server image by creating a sample WLS 12.2.1.3 domain and cluster. Utility scripts are copied into the image, enabling users to plug Node Manager automatically into the Administration Server running on another container.
 
-The Dockerfile uses the `createDomain` script from the Oracle WebLogic Deploy Tooling (WDT) to create the domain from a text-based model file. More information about WDT is available in the README file for the WDT project in GitHub:
+The Dockerfile uses the `createDomain` script from the WebLogic Deploy Tooling (WDT) to create the domain from a text-based model file. More information about WDT is available in the README file for the WDT project in GitHub:
 
 `https://github.com/oracle/weblogic-deploy-tooling`
 
@@ -13,7 +13,7 @@ This sample includes a basic WDT model, `simple-topology.yaml`, that describes t
 Another option is to use the WDT `discoverDomain` tool to create a model. This process is also described in the WDT project's README file. A user can use the tool to analyze an existing domain, and create a model based on its configuration. The user may choose to customize the model before using it to create a new Docker image.
 
 The sample model is accompanied by a properties file whose values can be changed to customize a domain. The model's variable tokens are replaced with values from 'simple-topology.properties' when building the docker image. The properties files can be created and modified using a text editor. Select variables in the properties file are used by the Dockerfile during the build to persist ENV variables and expose ports in the image.
- 
+
 Care should be taken to secure the credentials that are present in the model. The ADMIN credential attributes in the sample model have a file token referencing a special property file. Each special property file must only contain a single property and can be created and modified using a text editor. The sample includes the files adminuser.properties and the adminpass.properties in the properties/docker-build directory.
 
 See the README file for more information on using property and file tokens in the WDT model.
@@ -40,7 +40,7 @@ This sample deploys a simple, one-page web application contained in a ZIP archiv
 
     $ ./build-archive.sh
 
-The sample requires the Admin Host, Admin Port and Admin Name. It also requires the Managed Server port and the domain Debug 
+The sample requires the Admin Host, Admin Port and Admin Name. It also requires the Managed Server port and the domain Debug
   Port. The ports will be EXPOSED through Docker. The other arguments are persisted in the image to be used when running a
   container. If an attribute is not provided as a --build-arg on the build command, the following defaults are set.
 
@@ -75,12 +75,12 @@ This will use the model, variable and archive files in the sample directory.
 
 This sample provides a script which will read the model variable file and parse the domain, admin and managed server information
   into a string of --build-arg statements. This build arg string is exported as environment variable BUILD_ARG.
-  The sample script specifically parses the sample variable file. Use it as an example to parse a custom variable file. 
+  The sample script specifically parses the sample variable file. Use it as an example to parse a custom variable file.
   This will insure that the values docker exposes and persists in the image are the same values configured in the domain.
 
 To parse the sample variable file and build the sample, run:
 
-     $ container-scripts/setEnv.sh properties/docker-build/domain.properties 
+     $ container-scripts/setEnv.sh properties/docker-build/domain.properties
 
      $ docker build \
           $BUILD_ARG \
@@ -91,7 +91,7 @@ To parse the sample variable file and build the sample, run:
           -t 12213-domain1-wdt:1.0 .
 
 This sample provides a Derby Data Source that is targeted to the Managed Server cluster. The Derby database is created
-  in the Admin Server container when the container is run. To turn off the database create, set DERBY_FLAG="false" in the 
+  in the Admin Server container when the container is run. To turn off the database create, set DERBY_FLAG="false" in the
   runtime security.properties used on the docker run statement.
 
 The Admin Server and each Managed Server are run in containers from this build image. In the sample, the securities.properties file

site/config/target_env.md

@@ -18,17 +18,17 @@ This example would apply the `k8s` target type to the discovery result, and plac
 
 If a variable file is specified on the tool's command line using the `-variable_file` argument, any injected variables will be added to that file. If no variable file is specified, injected variables will be written to the file `<output-directory>/<target_name>_variable.properties`.
 
-### The Target Configuration File 
+### The Target Configuration File
 
 A target environment is configured in a JSON file at this location:
 ```
 $WLSDEPLOY_HOME/lib/target/<target-name>/target.json
 ```
 The `<target-name>` value corresponds to the value of the `-target` argument on the tool's command line. The WLS installation includes two pre-defined targets:
- - [Oracle Weblogic Server Kubernetes Operator](#the-oracle-weblogic-server-kubernetes-operator-target) (named `k8s`)
- - [Verrazzano](#the-verrazzano-target) (named `vz`). 
+ - [WebLogic Kubernetes Operator](#the-oracle-weblogic-kubernetes-operator-target) (named `k8s`)
+ - [Verrazzano](#the-verrazzano-target) (named `vz`).
 
-You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom Configuration](../tool_configuration.md#custom-configuration) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`. 
+You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom Configuration](../tool_configuration.md#custom-configuration) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
 
 Here is an example of a target environment file:
 ```
@@ -83,7 +83,7 @@ Template files can be customized for specific environments. The recommended meth
 
 These target environment configurations are included in the WebLogic Deploy Tooling installation.
 
-#### The Oracle WebLogic Server Kubernetes Operator Target
+#### The WebLogic Kubernetes Operator Target
 
 This target environment can be applied by providing the command-line argument `-target wko`. It will provide this additional processing:
 

site/discover.md

@@ -41,7 +41,7 @@ Before the model is persisted to the model file, any variable injectors or model
  - [Validate Model Tool](validate.md)
 
 
-The resulting model can also be modified for compatibility with specific target environments, such as Oracle Weblogic Server Kubernetes Operator. For more information, see [Target Environments](config/target_env.md).
+The resulting model can also be modified for compatibility with specific target environments, such as WebLogic Kubernetes Operator. For more information, see [Target Environments](config/target_env.md).
 
 Any problems (or success) will be listed in the discover tool summary. The summary will print the version of the tool and Oracle home, and the WLST mode with which the tool was run (online or offline). A recap of all Warning and Severe messages will be listed, along with a total. 
 

site/encrypt.md

@@ -2,11 +2,11 @@
 
 **NOTE: To meet Oracle's security standards, the encryption algorithms require JDK 8 to execute.**
 
-Models contain WebLogic Server domain configuration.  Certain types of resources and other configurations require passwords; for example, a JDBC data source requires the password for the user establishing the database connection.  When creating or configuring a resource that requires a password, that password must be specified either in the model directly or in the variable file.  Clear-text passwords are not conducive to storing configurations as source, so the Encrypt Model Tool gives the model author the ability to encrypt the passwords in the model and variable file using passphrase-based, reversible encryption.  When using a tool with a model containing encrypted passwords, the encryption passphrase must be provided, so that the tool can decrypt the password in memory to set the necessary WebLogic Server configuration (which supports its own encryption mechanism based on a domain-specific key).  While there is no requirement to use the Oracle WebLogic Server Deploy Tooling encryption mechanism, it is highly recommended because storing clear text passwords on disk is never a good idea.
+Models contain WebLogic Server domain configuration.  Certain types of resources and other configurations require passwords; for example, a JDBC data source requires the password for the user establishing the database connection.  When creating or configuring a resource that requires a password, that password must be specified either in the model directly or in the variable file.  Clear-text passwords are not conducive to storing configurations as source, so the Encrypt Model Tool gives the model author the ability to encrypt the passwords in the model and variable file using passphrase-based, reversible encryption.  When using a tool with a model containing encrypted passwords, the encryption passphrase must be provided, so that the tool can decrypt the password in memory to set the necessary WebLogic Server configuration (which supports its own encryption mechanism based on a domain-specific key).  While there is no requirement to use the WebLogic Deploy Tooling encryption mechanism, it is highly recommended because storing clear text passwords on disk is never a good idea.
 
 The Create, Update and Deploy tools can take a set of models. The Encrypt model will encrypt a set of models. Each model is encrypted using the same passphrase and written back to its original location.
 
-**NOTE: WebLogic Server Deploy Tooling also supports the use of domain-encrypted passwords directly in the model. The Encrypt Model Tool should not be used in tandem with this method.**  
+**NOTE: WebLogic Deploy Tooling also supports the use of domain-encrypted passwords directly in the model. The Encrypt Model Tool should not be used in tandem with this method.**  
 
 Start with the following example model:
 
@@ -52,7 +52,7 @@ topology:
     Security:
         Group:
             FriscoGroup:
-                Description: The WLS Deploy development group
+                Description: The WebLogic Deploy development group
         User:
             Robert:
                 Password: welcome1
@@ -210,4 +210,3 @@ The variable file will now look something like the following:
     db.url=mydb.example.com:1539/PDBORCL
     db.password={AES}czFXMkNFWNG9jNTNYd0hRL2R1anBnb0hDUlp4K1liQWFBdVM4UTlvMnE0NU1aMUZ5UVhiK25oaWFBc2lIQ20\=
     mymailsession.password={AES}RW9nRnUzcE41WGNMdnEzNDdRQVVNWm1LMGhidkFBVXg6OUN3aXcyci82cmh3cnpNQTpmY2UycUp5YWl4UT0\=
-

site/kubernetes.md

@@ -1,10 +1,10 @@
-## Using WDT with Oracle WebLogic Server Kubernetes Operator
+## Using WDT with WebLogic Kubernetes Operator
 
-The Extract Domain Resource Tool can be used to create a domain resource file for use with the Oracle WebLogic Server Kubernetes Operator. This allows the domain configuration and the Kubernetes container configuration to be specified in a single model file.
+The Extract Domain Resource Tool can be used to create a domain resource file for use with the WebLogic Kubernetes Operator. This allows the domain configuration and the Kubernetes container configuration to be specified in a single model file.
 
 This is especially useful when making configuration changes to the domain that also need to be reflected in the domain resource file. For example, adding a cluster to the domain only requires that it be added to the `topology` section of the WDT model, then a new domain resource file can be generated to apply to Kubernetes.
 
-More information about the Oracle WebLogic Server Kubernetes Operator can be found [here](https://oracle.github.io/weblogic-kubernetes-operator).
+More information about the WebLogic Kubernetes Operator can be found [here](https://oracle.github.io/weblogic-kubernetes-operator).
 
 NOTE: The Extract Domain Resource Tool is available with WDT releases 1.7.0 and later.
 
@@ -106,7 +106,7 @@ If clusters are specified in the `kubernetes/spec` section of the model, those c
 
 If the WDT model has a value of `Never` for `spec/imagePullPolicy`, the `imagePullSecrets` default value will not be added.
 
-A full list of sections and variables supported by the Oracle WebLogic Server Kubernetes Operator is available [here](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/docs/domains/Domain.md).
+A full list of sections and variables supported by the WebLogic Kubernetes Operator is available [here](https://github.com/oracle/weblogic-kubernetes-operator/blob/master/docs/domains/Domain.md).
 
 The Extract Domain Resource Tool supports a subset of these sections, including `metadata`, `serverPod`, and `spec`.