From df017bf0f883bce2151869c1d64f27cee12d6c2b Mon Sep 17 00:00:00 2001 From: RichardHoch Date: Sun, 14 Jul 2024 16:16:01 +0300 Subject: [PATCH] Fix broken links in Rules development guide --- docs/topics/create-first-yaml-rule.adoc | 14 +++--- docs/topics/create-yaml-rule.adoc | 2 +- docs/topics/review-existing-rules.adoc | 2 +- docs/topics/rules-important-links.adoc | 4 +- .../topics/templates/document-attributes.adoc | 2 +- docs/topics/testing-rules.adoc | 10 ++-- docs/topics/yaml-rule-structure-syntax.adoc | 46 +++++++++---------- 7 files changed, 38 insertions(+), 42 deletions(-) diff --git a/docs/topics/create-first-yaml-rule.adoc b/docs/topics/create-first-yaml-rule.adoc index 94cb5fd8f0..4998bd24df 100644 --- a/docs/topics/create-first-yaml-rule.adoc +++ b/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) - <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+"] ---- @@ -157,7 +157,7 @@ The rule is now complete and looks similar to the following: == Testing the rule .Procedure -To test the rule, point the input to the test data you created and pass the rule using the rules option in MTA CLI: +* To test the rule, point the input to the test data you created and pass the rule using the rules option in MTA CLI: [options="nowrap",subs="attributes+"] ---- diff --git a/docs/topics/create-yaml-rule.adoc b/docs/topics/create-yaml-rule.adoc index dbca33b02a..676ecfceb7 100644 --- a/docs/topics/create-yaml-rule.adoc +++ b/docs/topics/create-yaml-rule.adoc @@ -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` diff --git a/docs/topics/review-existing-rules.adoc b/docs/topics/review-existing-rules.adoc index 4172e0a90c..0f59719b3b 100644 --- a/docs/topics/review-existing-rules.adoc +++ b/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 diff --git a/docs/topics/rules-important-links.adoc b/docs/topics/rules-important-links.adoc index 35db891e97..464948dba4 100644 --- a/docs/topics/rules-important-links.adoc +++ b/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: windup-eng@redhat.com diff --git a/docs/topics/templates/document-attributes.adoc b/docs/topics/templates/document-attributes.adoc index 7810f309e2..24576cafa4 100644 --- a/docs/topics/templates/document-attributes.adoc +++ b/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 diff --git a/docs/topics/testing-rules.adoc b/docs/topics/testing-rules.adoc index d4f18919e5..1534c496de 100644 --- a/docs/topics/testing-rules.adoc +++ b/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 `` element has no unique attributes or child elements. [discrete] ===== Summary -The `` 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 `` 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 `` element has no unique child elements. [id="classification_exists_syntax_{context}"] ==== syntax -The `` 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 `` 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,7 @@ The `` has no unique child elements. [id="hint-exists-syntax_{context}"] ==== syntax -The `` 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 `` element. For additional information, see the link:{LinkAPI}org/jboss/windup/reporting/config/HintExists.html[HintExists] class. +The `` 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 `` element. For additional information, see the link:{LinkAPI}reporting/api/src/main/java/org/jboss/windup/reporting/config/HintExists.java[HintExists] class. [IMPORTANT] ==== diff --git a/docs/topics/yaml-rule-structure-syntax.adoc b/docs/topics/yaml-rule-structure-syntax.adoc index e252b22f19..aadf9fd4ca 100644 --- a/docs/topics/yaml-rule-structure-syntax.adoc +++ b/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 `.`: @@ -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: "" <1> 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: "" <2> lowerbound: "" <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: "" <2> lowerbound: "" <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. \ No newline at end of file