reorg ala Derek

Author: rosemarymarano

documentation/1.9/content/KnownIssues.md

@@ -22,19 +22,19 @@ For detailed information, see [WDT Tools]({{< relref "/userguide/tools/" >}}).
 ***
 ### Current production release
 
-The current [release](https://github.com/oracle/weblogic-deploy-tooling/releases) of WebLogic Deploy Tooling is 1.9.12. This release was published on April, 29, 2021.
+WebLogic Deploy Tooling version and release information is found [here](https://github.com/oracle/weblogic-deploy-tooling/releases).
 ***
 ### Recent changes and known issues
 
-See the [Release Notes]({{< relref "/release-notes.md" >}}) for recent changes, known issues, and workarounds.
+See the [Release Notes]({{< relref "/release-notes.md" >}}) for known issues and workarounds.
 
 ### About this documentation
 
 This documentation includes sections targeted to different audiences:
 
-* [Concepts]({{< relref "/concepts/" >}}) explains the underlying metadata models, archive files, tool configuration, and target environments.
+* [Concepts]({{< relref "/concepts/" >}}) explains the underlying metadata models and archive files.
 * The [User guide]({{< relref "/userguide/" >}}) contains detailed usage information, including how to install and configure WebLogic Deploy Tooling, and how to use each tool.
-* The [Samples]({{< relref "/samples/" >}}) provide detailed example code and instructions that show you how to perform various tasks.
+* The [Samples]({{< relref "/samples/" >}}) provide informative use case scenarios.
 * The [Developer guide]({{< relref "/developer/" >}}) provides details for people who want to understand how WDT is built, its features mapped and implemented.
 
 

documentation/1.9/content/_index.md

@@ -257,7 +257,7 @@ This feature can also remove items that were created by WebLogic Server template
                 ...
 ```
 
-This feature does not apply to named security providers within a realm. These items follow a special set of rules that are required to maintain their ordering. See [Modeling Security Providers]({{< relref "/concepts/use_cases#modeling-security-providers" >}}) for detailed information.
+This feature does not apply to named security providers within a realm. These items follow a special set of rules that are required to maintain their ordering. See [Modeling Security Providers]({{< relref "/samples/use_cases#modeling-security-providers" >}}) for detailed information.
 
 This feature cannot be use to un-deploy applications or remove libraries.
 

documentation/1.9/content/concepts/model.md

@@ -1,11 +1,17 @@
-# WebLogic Deploy Tooling Project Release Process
+---
+title: "WDT Project Release Process"
+date: 2019-02-23T17:19:24-05:00
+draft: false
+weight: 5
+---
+
 This document describes the process that should be followed to create a WebLogic Deploy Tooling (WDT) release.
 
-## Prerequisites
+### Prerequisites
 - A local installation of WebLogic Server 12.2.1.x must be available.
-- The person running the release process must have admin privileges on the [WebLogic Deploy Tooling GitHub repo](https://github.com/oracle/weblogic-deploy-tooling) since the release process pushes to the master branch directly.
+- The person running the release process must have admin privileges on the [WebLogic Deploy Tooling GitHub repo](https://github.com/oracle/weblogic-deploy-tooling) because the release process pushes to the master branch directly.
 - The person running the release process needs to create a GitHub Personal Access Token for the repository with (at least) the `repo:status`, `repo_deployment`, `public_repo`, and `security_events` privileges.
-- The person running the release needs a server added to their Maven `settings.xml` where the GitHub Personal Access Token is stored, as shown below.  Note that this token can either be stored in plain text of encrypted using [Maven password encryption](https://maven.apache.org/guides/mini/guide-encryption.html).
+- The person running the release needs a server added to their Maven `settings.xml` file, where the GitHub Personal Access Token is stored, as shown below.  Note that this token can either be stored in plain text or encrypted using [Maven password encryption](https://maven.apache.org/guides/mini/guide-encryption.html).
 
 ```xml
   <servers>
@@ -16,23 +22,23 @@ This document describes the process that should be followed to create a WebLogic
   </servers>
 ```
 
-## Software Release Process
+### Software Release Process
 The best practice is to write the release notes that will be published to GitHub prior to starting the steps below.
 
 1. Set (and export) the environment variable `WLST_DIR` to `<WLS-install-dir>/oracle_common/common/bin`, replacing `<WLS-install-dir>` with the full path to the WLS 12.2.1.x installation directory.
-2. In the weblogic-deploy-tooling project directory, create a file called `release.properties` with content similar to the example shown below.  Note that the example is configured to cut the 1.9.11 release.
+2. In the `weblogic-deploy-tooling` project directory, create a file called `release.properties` with content similar to the example shown below.  Note that the example is configured to cut the 1.9.11 release.
 
 ```properties
 tag=release-1.9.11
 releaseVersion=1.9.11
 developmentVersion=1.9.12-SNAPSHOT
 ```
 
-3. In the weblogic-deploy-tooling project directory, run the `mvn -B -P release release:prepare release:perform` command.  If your SSH private key has a passphrase, watch the build closely since it will prompt for your passphrase multiple times.  Failure to enter it in a timely manner may result in a failure.
-4. If the build fails, run the `mvn -B -P release release:rollback` command to undo it and start over from Step 2 after correcting the issue.
-5. Once the software has been released, move on to the GitHub Release Process.
+3. In the `weblogic-deploy-tooling` project directory, run the `mvn -B -P release release:prepare release:perform` command.  If your SSH private key has a passphrase, watch the build closely because it will prompt for your passphrase multiple times.  Failure to enter it in a timely manner may result in a failure.
+4. If the build fails, run the `mvn -B -P release release:rollback` command to undo it and start over from Step 2., after correcting the issue.
+5. After the software has been released, move on to the GitHub Release Process.
 
-## GitHub Release Process
+### GitHub Release Process
 Note that this process relies on the WDT installers being in your local Maven repository.  As such, it is critical for the same user to run these steps on the same machine as the steps from the previous section!
 
 1. Save the release notes in the file `<wdt-project-directory>/target/ReleaseNotes.md`.

documentation/1.9/content/ReleaseProcess.md renamed to documentation/1.9/content/developer/ReleaseProcess.md

@@ -0,0 +1,9 @@
++++
+title = "Reference"
+date = 2019-02-22T15:27:54-05:00
+weight = 5
+chapter = true
+pre = "<b>5. </b>"
++++
+
+# Reference

documentation/1.9/content/reference/_index.md

@@ -2,14 +2,14 @@
 title: "Tools Configuration"
 date: 2019-02-23T17:19:24-05:00
 draft: false
-weight: 4
+weight: 2
 ---
 
 
 #### Contents
  - [Tool Property File](#tool-property-file)
  - [Model Filters](#model-filters)
- - [Target Environments]({{< relref "/concepts/target_env.md" >}})
+ - [Target Environments]({{< relref "/userguide/target_env.md" >}})
  - [Type Definitions](#domain-type-definitions)
  - [Variable Injection]({{< relref "/userguide/tools/variable_injection.md" >}})
  - [Custom Configuration](#custom-configuration)

documentation/1.9/content/concepts/tool_configuration.md renamed to documentation/1.9/content/reference/tool_configuration.md

@@ -1,25 +1,3 @@
-#### WDT Version 1.9.12
-
-Additional features in this release:
-
-* FMW Platform specific patches are now included in `--recommendedPatches` for all WLS-based installer types.
-* Java Required Files specific patches are now included in `--recommendedPatches` for all FMW-based installer types.
-
-Issues addressed in this release:
-
-* Increased the default version of HTTP retries to 10 to improve reliability with retrieving patch information from Oracle.
-
-
-#### WDT Version 1.9.11
-
-Issues addressed in this release:
-
-* Fixed validate process to recognize float values as strings.
-* Fixed JMS Server issue with jarray in store.
-* Fixed issue with recognizing NodeManager properties user and password as credentials.
-* Fixed discovery of SAFRemoteContext.
-* Fixed discovery of ServerTemplate DataSource.
-
 #### Known Issues for WebLogic Deploy Tooling
 
 The following list contains known issues. Each issue may contain a workaround or an associated issue number.

documentation/1.9/content/release-notes.md

@@ -5,7 +5,6 @@ weight = 3
 chapter = true
 pre = "<b>3. </b>"
 +++
-# Samples
+# Model Use Cases
 
-The samples provide demonstrations of how to accomplish common tasks.
-These samples are provided for educational and demonstration purposes only; they are not intended to be used in production deployments or to be depended upon to create production environments.
+These typical use case scenarios show you how some common configurations can be represented in the model.

documentation/1.9/content/samples/_index.md

@@ -2,7 +2,7 @@
 title: "Model Use Cases"
 date: 2019-02-23T17:19:24-05:00
 draft: false
-weight: 3
+weight: 1
 ---
 
 
@@ -22,7 +22,7 @@ weight: 3
 
  ### Administration Server Configuration
 
- The Create Domain Tool allows you to configure the Administration Server using a domain model. These examples show how some common configurations can be represented in the model.
+ The Create Domain Tool lets you configure the Administration Server using a domain model. These examples show how some common configurations can be represented in the model.
 
  #### Using the Default Administration Server Configuration
 
@@ -80,7 +80,7 @@ weight: 3
  The name of the Administration Server cannot be changed after domain creation, so any changes to the `AdminServerName` attribute will be ignored by the Update Domain Tool.
 
 
- #### Configured Cluster Sample
+ ### Configured Cluster Sample
 
  This WDT domain model sample section has a typical configuration for a configured cluster with a single managed server, including connection information, logging setup, and other details.
 
@@ -130,7 +130,7 @@ weight: 3
  For this sample, the machine named `machine-1` and the data source named `jdbc-1` should be defined elsewhere within this model, or should already exist in a domain that is being updated.
 
 
- #### JDBC Sample
+ ### JDBC Sample
 
  This WDT domain model sample section has a typical configuration for a JDBC data source, including targeting information, connection pool parameters, and other details.
 
@@ -166,7 +166,7 @@ weight: 3
  It is recommended that credential fields, such as `PasswordEncrypted`, should not be stored as clear text in the model. Those values can be referenced in a separate variables file or in Kubernetes secrets, or the model can be encrypted using the [Encrypt Model Tool]({{< relref "/userguide/tools/encrypt.md" >}}).
 
 
- #### Work Manager Sample
+ ### Work Manager Sample
 
  This WDT domain model sample section has typical configurations for a Work Manager and its related request classes and constraints. These elements are configured in the `SelfTuning` folder in the `resources` section of the model.
  ```yaml
@@ -518,7 +518,7 @@ domainInfo:
 
  In order to configure and use OHS, it must be installed in the Oracle Home directory used to create the domain. You can download OHS [here](https://www.oracle.com/middleware/technologies/webtier-downloads.html).
 
- The OHS template must be present in the WDT domain type definition file used to create or update the domain. For more information on creating a custom definition, see [Domain Type Definitions]({{< relref "/concepts/tool_configuration#domain-type-definitions" >}}).
+ The OHS template must be present in the WDT domain type definition file used to create or update the domain. For more information on creating a custom definition, see [Domain Type Definitions]({{< relref "/reference/tool_configuration#domain-type-definitions" >}}).
 
  You create a copy of an existing domain type definition file, add the template to that file, and then reference that file on the WDT command line. For example, if you want to create a domain with Oracle HTTP Server based on a Restricted JRF domain, then you would first create a copy of the file `WLSDEPLOY_HOME/lib/typedefs/RestrictedJRF.json` in the same directory, such as `WLSDEPLOY_HOME/lib/typedefs/HttpServer.json`. In this example, you would change the existing `extensionTemplates` section to include the additional OHS template. The original value is:
  ```

documentation/1.9/content/concepts/use_cases.md renamed to documentation/1.9/content/samples/use_cases.md

@@ -2,14 +2,14 @@
 title: "Target environments"
 date: 2019-02-23T17:19:24-05:00
 draft: false
-weight: 5
+weight: 2
 ---
 
 
 The [Discover Domain]({{< relref "/userguide/tools/discover.md" >}}) and [Prepare Model]({{< relref "/userguide/tools/prepare.md" >}}) Tools allow you to customize the model and other files produced to be compatible with a specific target environment. Options for a target environment may include:
 - Using model tokens for some attributes in the model. See [Model Tokens]({{< relref "/concepts/model#model-tokens" >}}).
 - Using Kubernetes secrets for credentials in the model.
-- Applying filters to the model. See [Model Filters]({{< relref "/concepts/tool_configuration#model-filters" >}}).
+- Applying filters to the model. See [Model Filters]({{< relref "/reference/tool_configuration#model-filters" >}}).
 - Creating additional configuration files for the target system.
 
 ### Specifying a target environment
@@ -34,7 +34,7 @@ The `<target-name>` value corresponds to the value of the `-target` argument on
  - [Weblogic Kubernetes Operator](#the-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]({{< relref "/concepts/tool_configuration#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]({{< relref "/reference/tool_configuration#custom-configuration" >}}) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
 
 Here is an example of a target environment file:
 ```
@@ -55,7 +55,7 @@ Each of the fields in this example is optional, and can be customized.
 
 #### `model_filters`
 
-This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model Filters]({{< relref "/concepts/tool_configuration#model-filters" >}}) configuration. The `discover` type should always be used here.
+This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model Filters]({{< relref "/reference/tool_configuration#model-filters" >}}) configuration. The `discover` type should always be used here.
 
 The `@@TARGET_CONFIG_DIR@@` token can be used to indicate that the specified filter is in the same directory as the target configuration file.