Merge pull request #16 from RichardHoch/71_broken_links_rules_dev

Fix broken links in MTV 7.1 Rules development guide

Author: RichardHoch

docs/topics/create-first-yaml-rule.adoc

@@ -2,7 +2,7 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="create-first-yaml-rule_{context}"]
 = Creating your first YAML rule
 
@@ -13,7 +13,7 @@ In this example, you will create a rule to discover instances where an applicati
 [id="creating-yaml-file-for-the-rule_{context}"]
 == Creating a YAML file for the rule
 
-Create a YAML file for your first rule.
+* Create a YAML file for your first rule.
 
 [options="nowrap",subs="attributes+"]
 ----
@@ -82,7 +82,7 @@ when(condition)
 
 .Procedure
 
-. In the `rule.yaml` file you created, paste the following contents:
+* In the `rule.yaml` file you created, paste the following contents:
 +
 [options="nowrap",subs="attributes+"]
 ----
@@ -97,10 +97,10 @@ when(condition)
   - <LINKS> <7>
 ----
 +
-<1> Unique ID for your rule, for instance, `jboss5-web-class-loading`.
+<1> Unique ID for your rule. For example, `jboss5-web-class-loading`.
 <2> Text description of the rule.
 <3> Complete the `when` block specifying one or more conditions:
-.. Use the `builtin` provider’s XML capability because this rule checks for a match in an XML file.
+.. Use the `builtin` provider's XML capability because this rule checks for a match in an XML file.
 .. To match on the `class-loading` element that is a child of `jboss-web`, use the XPath expression `jboss-web/web-loading` as an XML query. In this case, you need just one condition:
 +
 [options="nowrap",subs="attributes+"]
@@ -146,7 +146,7 @@ The rule is now complete and looks similar to the following:
 == Installing the rule
 
 .Procedure
-. Point the CLI  to the rule file you created :
+* Point the CLI to the rule file you created :
 +
 [options="nowrap",subs="attributes+"]
 ----

docs/topics/create-yaml-rule.adoc

@@ -2,7 +2,7 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="create-yaml-rule_{context}"]
 = Creating a YAML rule
 
@@ -125,7 +125,7 @@ The table below lists all available providers, their capabilities, and their fie
 |Yes
 |Finds files with names matching this pattern
 |`hasTags`
-3+>|This is an inline list of string tags. See _Tag Action_ for details on tag format.
+3+^| This is an inline list of string tags. See *Tag Actions* in xref:yaml-rule-actions_{context}[Rule Actions] for details on tag format.
 
 .5+.^|`go`
 |`referenced`

docs/topics/review-existing-rules.adoc

@@ -2,7 +2,7 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: PROCEDURE
+:_mod-docs-content-type: PROCEDURE
 [id="review-existing-rules_{context}"]
 = Reviewing existing {ProductShortName} XML rules
 

docs/topics/rules-important-links.adoc

@@ -2,10 +2,10 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: REFERENCE
+:_mod-docs-content-type: REFERENCE
 [id="rules-important-links_{context}"]
 = Additional resources
 
-* {ProductShortName} Javadoc: http://windup.github.io/windup/docs/latest/javadoc
+// * {ProductShortName} Javadocs: {LinkAPI}reporting/api/src/main/java
 * {ProductShortName} Jira issue tracker: {JiraWindupURL}
 * {ProductShortName} mailing list: [email protected]

docs/topics/templates/document-attributes.adoc

@@ -105,7 +105,7 @@ endif::[]
 :ProductDocVscGuideURL: https://access.redhat.com/documentation/en-us/{DocInfoProductNameURL}/{DocInfoProductNumber}/html-single/visual_studio_code_extension_guide
 :ProductDocIntelliJGuideURL: https://access.redhat.com/documentation/en-us/{DocInfoProductNameURL}/{DocInfoProductNumber}/html-single/intellij_idea_plugin_guide
 :OpenShiftDocsURL: https://docs.openshift.com/container-platform/{OpenShiftProductNumber}
-:LinkAPI: http://windup.github.io/windup/docs/latest/javadoc/
+:LinkAPI: https://github.com/windup/windup/blob/master/
 
 //Links to MTA and MTR Jira project pages:
 :JiraMTRURL: https://issues.redhat.com/projects/WINDUP

docs/topics/testing-rules.adoc

@@ -2,7 +2,7 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: REFERENCE
+:_mod-docs-content-type: REFERENCE
 [id="testing-rules_{context}"]
 = Testing XML rules
 
@@ -17,7 +17,7 @@ Test rules are created using a process similar to the process for creating an XM
 * Test rules should use the `.windup.test.xml` extension.
 * These rules use the structure defined in the Test XML Rule Structure.
 
-In addition, it is recommended to create a test rule that follows the name of the rule it tests. For instance, if a rule were created with a filename of `proprietary-rule.{LC_PSN}.xml`, the test rule should be called `proprietary-rule.windup.test.xml`.
+In addition, it is recommended to create a test rule that follows the name of the rule it tests. For example, if a rule were created with a filename of `proprietary-rule.{LC_PSN}.xml`, the test rule should be called `proprietary-rule.windup.test.xml`.
 
 [id="test-xml-rule-structure_{context}"]
 === Test XML rule structure
@@ -99,7 +99,7 @@ The `<not>` element has no unique attributes or child elements.
 [discrete]
 ===== Summary
 
-The `<iterable-filter>` element counts the number of times a condition is verified. For additional information, see the link:{LinkAPI}org/jboss/windup/rules/general/IterableFilter.html[IterableFilter] class.
+The `<iterable-filter>` element counts the number of times a condition is verified. For additional information, see the link:{LinkAPI}rules-base/api/src/main/java/org/jboss/windup/rules/general/IterableFilter.java[IterableFilter] class.
 
 The following is an example that looks for four instances of the specified message.
 
@@ -158,7 +158,7 @@ The `<iterable-filter>` element has no unique child elements.
 [id="classification_exists_syntax_{context}"]
 ==== <classification-exists> syntax
 
-The `<classification-exists>` element determines if a specific classification title has been included in the analysis. For additional information, see the link:{LinkAPI}org/jboss/windup/reporting/config/ClassificationExists.html[ClassificationExists] class.
+The `<classification-exists>` element determines if a specific classification title has been included in the analysis. For additional information, see the link:{LinkAPI}reporting/api/src/main/java/org/jboss/windup/reporting/config/ClassificationExists.java[ClassificationExists] class.
 
 [IMPORTANT]
 ====
@@ -226,7 +226,8 @@ The `<classification-exists>` has no unique child elements.
 [id="hint-exists-syntax_{context}"]
 ==== <hint-exists> syntax
 
-The `<hint-exists>` element determines if a specific hint has been included in the analysis. It searches for any instances of the defined message, and is typically used to search for the beginning or a specific class inside of a `<message>` element. For additional information, see the link:{LinkAPI}org/jboss/windup/reporting/config/HintExists.html[HintExists] class.
+The `<hint-exists>` element determines if a specific hint has been included in the analysis. It searches for any instances of the defined message, and is typically used to search for the beginning or a specific class inside of a `<message>` element. For additional information, see the link:{LinkAPI}reporting/api/src/main/java/org/jboss/windup/reporting/config/HintExists.java[HintExists] class.
+
 
 [IMPORTANT]
 ====

docs/topics/yaml-rule-structure-syntax.adoc

@@ -2,7 +2,7 @@
 //
 // * docs/rules-development-guide/master.adoc
 
-:_content-type: REFERENCE
+:_mod-docs-content-type: REFERENCE
 [id="yaml-rule-structure-syntax_{context}"]
 = YAML rule structure and syntax
 
@@ -31,11 +31,8 @@ effort: 1 <3>
 category: mandatory <4>
 ----
 <1> The ID must be unique within the ruleset to which the rule belongs.
-
 <2> See below for a description of the label format.
-
 <3> `effort` is an integer value that indicates the level of effort needed to fix this issue.
-
 <4> `category` describes the severity of the issue for migration. The value can be either `mandatory`, `optional` or `potential`. For a description of these categories, see xref:yaml-rule-categories_{context}[Rule categories].
 
 [id="yaml-rule-labels_{context}"]
@@ -118,7 +115,7 @@ _Examples:_
 
 .Dependency labels
 
-The analyzer engine adds labels to dependencies. These labels provide additional information about a dependency, such as its programming language and whether the dependency is open-source or internal.
+The analyzer engine adds labels to dependencies. These labels provide additional information about a dependency, such as its programming language and whether the dependency is open source or internal.
 
 Currently, the analyzer adds the following labels to dependencies:
 
@@ -133,9 +130,9 @@ labels:
 
 The analyzer CLI accepts the `--dep-label-selector` option, which allows filtering-in or filtering-out incidents generated from a dependency by their labels.
 
-For example, the analyzer adds a `konveyor.io/dep-source` label to dependencies with a value that indicates whether the dependency is a known open-source dependency.
+For example, the analyzer adds a `konveyor.io/dep-source` label to dependencies with a value that indicates whether the dependency is a known open source dependency.
 
-To exclude incidents for all such open-source dependencies, you can use `--dep-label-selector` as follows:
+To exclude incidents for all such open source dependencies, you can use `--dep-label-selector` as follows:
 
 `konveyor-analyzer ... --dep-label-selector !konveyor.io/dep-source=open-source`
 
@@ -233,7 +230,7 @@ when:
 
 ==== Provider conditions
 
-{ProductShortName} supports multi-language source code analysis. Searching for a specific language in the source code is enabled using the `provider` condition. This condition defines a search query for a specific language provider.  The `provider` condition also specifies which of the provider's "capabilities" to use for analyzing the code.
+{ProductShortName} supports multi-language source code analysis. Searching for a specific language in the source code is enabled using the `provider` condition. This condition defines a search query for a specific language provider. The `provider` condition also specifies which of the provider's "capabilities" to use for analyzing the code.
 
 The `provider` condition has the form `<provider_name>.<capability>`:
 
@@ -320,12 +317,12 @@ The `hasTags` capability enables the provider to query application tags. It quer
 [source,terminal]
 ----
 when:
-  # when more than one tags are given, a logical AND is implied
+  # when more than one tag is given, a logical AND is implied
   hasTags: <1>
     - "tag1"
     - "tag2"
 ----
-<1> When more than one tags is given, a logical AND is implied.
+<1> When more than one tag is given, a logical AND is implied.
 
 ===== `java` provider
 
@@ -334,7 +331,7 @@ The `java` provider analyzes Java source code.
 This provider has the following capabilities:
 
 * `referenced`
-* `dependency`.
+* `dependency`
 
 .`referenced`
 
@@ -347,8 +344,8 @@ when:
     pattern: "<pattern>" <1>
     location: "<location>" <2>
 ----
-<1> A RegEx pattern to match, for example, `org.kubernetes.*`
-<2> Specifies the exact location where the pattern needs to be matched, for example, `IMPORT`
+<1> A regular expression pattern to match, for example, `org.kubernetes.*`.
+<2> Specifies the exact location where the pattern needs to be matched, for example, `IMPORT`.
 
 The supported locations are the following:
 
@@ -375,13 +372,13 @@ when:
     upperbound: "<version_string>" <2>
     lowerbound: "<version_string>" <3>
 ----
-<1> Name of the dependency to search for
-<2> Upper bound on the version of the dependency
-<3> Lower bound on the version of the dependency
+<1> Name of the dependency to search for.
+<2> Upper bound on the version of the dependency.
+<3> Lower bound on the version of the dependency.
 
 ===== `go` provider
 
-The `go` provider analyzes Go source code.  This provider's capabilities are `referenced` and `dependency`.
+The `go` provider analyzes Go source code. This provider's capabilities are `referenced` and `dependency`.
 
 .`referenced`
 
@@ -405,13 +402,13 @@ when:
     upperbound: "<version_string>" <2>
     lowerbound: "<version_string>" <3>
 ----
-<1> Name of the dependency to search for
-<2> Upper bound on the version of the dependency
-<3> Lower bound on the version of the dependency
+<1> Name of the dependency to search for.
+<2> Upper bound on the version of the dependency.
+<3> Lower bound on the version of the dependency.
 
 ==== Custom variables
 
-Provider conditions can have associated custom variables. You can use custom variables to capture relevant information from the matched line in the source code. The values of these variables are interpolated with data matched in the source code. These values can be used to generate detailed templated messages in a rule’s action (see xref:yaml-rule-actions_{context}[Message actions]). They can be added to a rule in the `customVariables` field:
+Provider conditions can have associated custom variables. You can use custom variables to capture relevant information from the matched line in the source code. The values of these variables are interpolated with data matched in the source code. These values can be used to generate detailed templated messages in a rule's action (see xref:yaml-rule-actions_{context}[Message actions]). They can be added to a rule in the `customVariables` field:
 
 [source,terminal]
 ----
@@ -426,9 +423,9 @@ Provider conditions can have associated custom variables. You can use custom var
           pattern: com.example.apps.GenericClass.get
 
 ----
-<1> `pattern`: A RegEx pattern that is matched on the source code line when a match is found
-<2> `name`: The name of the variable that can be used in templates
-<3> `message`: A template for a message using a custom variable
+<1> `pattern`: A regular expression pattern that is matched on the source code line when a match is found.
+<2> `name`: The name of the variable that can be used in templates.
+<3> `message`: A template for a message using a custom variable.
 
 
 === Logical conditions
@@ -521,5 +518,4 @@ labels: <2>
   - key=val
 ----
 <1> The name must be unique within the provided rulesets.
-
 <2> Ruleset labels are inherited by all rules that belong to the ruleset.