Skip to content

Commit

Permalink
Merge pull request windup#900 from RichardHoch/broken_links_rules_dev
Browse files Browse the repository at this point in the history
Fix broken links in Rules development guide (MTA 7.0)
  • Loading branch information
RichardHoch authored Jul 22, 2024
2 parents 6ee8e58 + df017bf commit 61244ef
Show file tree
Hide file tree
Showing 7 changed files with 38 additions and 42 deletions.
14 changes: 7 additions & 7 deletions docs/topics/create-first-yaml-rule.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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+"]
----
Expand Down Expand Up @@ -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+"]
----
Expand All @@ -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` providers 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+"]
Expand Down Expand Up @@ -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+"]
----
Expand All @@ -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+"]
----
Expand Down
2 changes: 1 addition & 1 deletion docs/topics/create-yaml-rule.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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`
Expand Down
2 changes: 1 addition & 1 deletion docs/topics/review-existing-rules.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
4 changes: 2 additions & 2 deletions docs/topics/rules-important-links.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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]
2 changes: 1 addition & 1 deletion docs/topics/templates/document-attributes.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
10 changes: 5 additions & 5 deletions docs/topics/testing-rules.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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]
====
Expand Down Expand Up @@ -226,7 +226,7 @@ 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]
====
Expand Down
46 changes: 21 additions & 25 deletions docs/topics/yaml-rule-structure-syntax.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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}"]
Expand Down Expand Up @@ -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:

Expand All @@ -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`

Expand Down Expand Up @@ -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>`:

Expand Down Expand Up @@ -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

Expand All @@ -334,7 +331,7 @@ The `java` provider analyzes Java source code.
This provider has the following capabilities:

* `referenced`
* `dependency`.
* `dependency`

.`referenced`

Expand All @@ -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:

Expand All @@ -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`

Expand All @@ -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 rules 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]
----
Expand All @@ -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
Expand Down Expand Up @@ -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.

0 comments on commit 61244ef

Please sign in to comment.