Fix cross references

Author: rwinch

spring-shell-docs/modules/ROOT/pages/getting-started.adoc

@@ -93,7 +93,7 @@ Or in non-interactive mode:
 ----
 ====
 
-TIP: Check out <<using-shell-customization-logging>> making logging to work
+TIP: Check out xref:using-shell-customization-logging.adoc[Logging] making logging to work
 better with shell apps.
 
 [[using-spring-shell-your-first-command]]

spring-shell-docs/modules/ROOT/pages/using-shell-basics-reading.adoc

@@ -4,8 +4,8 @@
 Throughout this documentation, we make references to configuring something by using
 annotations or programmatic examples.
 
-NOTE: There are two annotation models, <<commands-registration-annotation, annotations>>
-referred to new annotation model, <<commands-registration-legacyannotation, legacy annotations>>
+NOTE: There are two annotation models, xref:using-shell-commands-registration-annotation.adoc[annotations]
+referred to new annotation model, xref:using-shell-commands-registration-legacyannotation.adoc[legacy annotations]
 referred to old legacy annotation model.
 
 Old legacy annotation model mostly relates to use of `@ShellMethod` and `@ShellOption` and

spring-shell-docs/modules/ROOT/pages/using-shell-commands-availability.adoc

@@ -57,7 +57,7 @@ Details of the error have been omitted. You can use the stacktrace command to pr
 ----
 ====
 
-Information about currently unavailable commands is also used in the integrated help. See <<built-in-commands-help>>.
+Information about currently unavailable commands is also used in the integrated help. See xref:using-shell-commands-builtin-help.adoc[Help].
 
 [TIP]
 ====

spring-shell-docs/modules/ROOT/pages/using-shell-commands-builtin-help.adoc

@@ -7,7 +7,7 @@ accessing a web browser or any other rich UI application (such as a PDF viewer)
 be possible. This is why it is important that the shell commands are correctly self-documented, and this is where the `help`
 command comes in.
 
-Typing `help` + `ENTER` lists all the commands known to the shell (including <<dynamic-command-availability,unavailable>> commands)
+Typing `help` + `ENTER` lists all the commands known to the shell (including xref:using-shell-commands-availability.adoc[unavailable] commands)
 and a short description of what they do, similar to the following:
 
 ====
@@ -96,10 +96,10 @@ as a model.
 |`true` if showing groups is enabled. Otherwise, false.
 
 |`groups`
-|The commands variables (see <<groupcommandinfomodel-variables>>).
+|The commands variables (see xref:using-shell-commands-builtin-help.adoc#groupcommandinfomodel-variables[GroupCommandInfoModel Variables]).
 
 |`commands`
-|The commands variables (see <<commandinfomodel-variables>>).
+|The commands variables (see xref:using-shell-commands-builtin-help.adoc#commandinfomodel-variables[CommandInfoModel Variables]).
 
 |`hasUnavailableCommands`
 |`true` if there is unavailable commands. Otherwise, false.
@@ -114,7 +114,7 @@ as a model.
 |The name of a group, if set. Otherwise, empty.
 
 |`commands`
-|The commands, if set. Otherwise, empty. Type is a multi value, see <<commandinfomodel-variables>>.
+|The commands, if set. Otherwise, empty. Type is a multi value, see xref:using-shell-commands-builtin-help.adoc#commandinfomodel-variables[CommandInfoModel Variables].
 |===
 
 [[commandinfomodel-variables]]
@@ -135,10 +135,10 @@ as a model.
 |The description of a command, if set. Otherwise, null.
 
 |`parameters`
-|The parameters variables, if set. Otherwise empty. Type is a multi value, see <<commandparameterinfomodel-variables>>.
+|The parameters variables, if set. Otherwise empty. Type is a multi value, see xref:using-shell-commands-builtin-help.adoc#commandparameterinfomodel-variables[CommandParameterInfoModel Variables].
 
 |`availability`
-|The availability variables (see <<commandavailabilityinfomodel-variables>>).
+|The availability variables (see xref:using-shell-commands-builtin-help.adoc#commandavailabilityinfomodel-variables[CommandAvailabilityInfoModel Variables]).
 |===
 
 [[commandparameterinfomodel-variables]]

spring-shell-docs/modules/ROOT/pages/using-shell-commands-interactionmode.adoc

@@ -4,7 +4,7 @@
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 Command registration can define `InteractionMode` which is used to hide commands
-depending which mode shell is executing. More about that in <<using-shell-execution-interactionmode>>.
+depending which mode shell is executing. More about that in xref:using-shell-execution.adoc#using-shell-execution-interactionmode[Interaction Mode].
 
 You can define it with `CommandRegisration`.
 

spring-shell-docs/modules/ROOT/pages/using-shell-commands-registration-legacyannotation.adoc

@@ -26,7 +26,7 @@ include::{snippets}/AnnotationRegistrationSnippets.java[tag=snippet1]
 
 The only required attribute of the `@ShellMethod` annotation is its `value` attribute, which should have
 a short, one-sentence, description of what the command does. This lets your users
-get consistent help about your commands without having to leave the shell (see <<built-in-commands-help>>).
+get consistent help about your commands without having to leave the shell (see xref:using-shell-commands-builtin-help.adoc[Help]).
 
 NOTE: The description of your command should be short -- no more than one or two sentences. For better
 consistency, it should start with a capital letter and end with a period.

spring-shell-docs/modules/ROOT/pages/using-shell-commands-registration-programmatic.adoc

@@ -19,7 +19,7 @@ be autowired. Default implementation of this supplier returns
 a new builder so you don't need to worry about its internal state.
 
 IMPORTANT: Commands registered programmatically automatically
-add _help options_ mentioned in <<commands-helpoptions>>.
+add _help options_ mentioned in xref:using-shell-commands-helpoptions.adoc[Help Options].
 
 If bean of this supplier type is defined then auto-configuration
 will back off giving you an option to redefine default functionality.

spring-shell-docs/modules/ROOT/pages/using-shell-commands-registration.adoc

@@ -10,8 +10,8 @@ In the programmatic model, you use a more low level approach, defining command
 registrations (either as beans or by dynamically registering with a command catalog).
 
 Starting from _3.1.x_ a better support for defining commands using
-<<commands-registration-annotation, annotations>> were added. Firstly because eventually standard
-package providing <<commands-registration-legacyannotation, legacy annotations>> will get deprecated
+xref:using-shell-commands-registration-annotation.adoc[annotations] were added. Firstly because eventually standard
+package providing xref:using-shell-commands-registration-legacyannotation.adoc[legacy annotations] will get deprecated
 and removed. Secondly so that we're able to provide same set of features than using underlying
 `CommandRegistration`. Creating new a annotation model allows us to rethink and modernise that
 part without breaking existing applications.

spring-shell-docs/modules/ROOT/pages/using-shell-commands.adoc

@@ -5,7 +5,7 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 In this section, we go through an actual command registration and leave command options
 and execution for later in a documentation. You can find more detailed info in
-<<appendix-tech-intro-registration>>.
+xref:appendices-techical-intro-registration.adoc[Command Registration].
 
 
 

spring-shell-docs/modules/ROOT/pages/using-shell-completion.adoc

@@ -65,4 +65,4 @@ include::{snippets}/CompletionSnippets.java[tag=anno-method]
 == Command-Line
 
 Command-line completion currently only support _bash_ and is documented
-in a built-in `completion` command <<built-in-commands-completion>>.
+in a built-in `completion` command xref:using-shell-commands-builtin-completion.adoc[Completion].

spring-shell-docs/modules/ROOT/pages/using-shell-components-flow.adoc

@@ -3,7 +3,7 @@
 
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
-When you use <<using-shell-components-ui>> to build something that involves
+When you use xref:using-shell-components-ui.adoc[Flow Components] to build something that involves
 use of a multiple components, your implementation may become a bit cluttered.
 To ease these use cases, we added a
 `ComponentFlow` that can hook multiple component executions together

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-confirmation.adoc

@@ -28,5 +28,5 @@ The context object is `ConfirmationInputContext`. The following table describes
 |The default value -- either `true` or `false`.
 
 |`model`
-|The parent context variables (see <<textcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
 |===

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-multiselect.adoc

@@ -31,5 +31,5 @@ The context object is `MultiItemSelectorContext`. The following table describes
 |The visible items, where rows contain maps of name, selected, on-row, and enabled items.
 
 |`model`
-|The parent context variables (see <<selectorcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#selectorcomponentcontext-template-variables[SelectorComponentContext Template Variables]).
 |===

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-pathinput.adoc

@@ -24,5 +24,5 @@ The context object is `PathInputContext`. The following table describes its cont
 |Key |Description
 
 |`model`
-|The parent context variables (see <<textcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
 |===

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-pathsearch.adoc

@@ -15,7 +15,7 @@ include::{snippets}/UiComponentSnippets.java[tag=snippet9]
 ====
 
 NOTE: Logic for search is passed as is into algorithms documented
-in <<appendix-tech-intro-searchalgorithm>>.
+in xref:appendices-techical-intro-searchalgorithm.adoc[Search Algorithms].
 
 The following image shows typical output from a path search component:
 
@@ -32,5 +32,5 @@ The context object is `PathSearchContext`. The following table describes its con
 |The items available for rendering search results.
 
 |`model`
-|The parent context variables (see <<textcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
 |===

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-singleselect.adoc

@@ -31,7 +31,7 @@ The context object is `SingleItemSelectorContext`. The following table describes
 |The visible items, where rows contains maps of name and selected items.
 
 |`model`
-|The parent context variables (see <<selectorcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#selectorcomponentcontext-template-variables[SelectorComponentContext Template Variables]).
 |===
 
 You can pre-select an item by defining it to get exposed. This is

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui-stringinput.adoc

@@ -40,5 +40,5 @@ The context object is `StringInputContext`. The following table lists its contex
 |`true` if a mask character is set. Otherwise, false.
 
 |`model`
-|The parent context variables (see <<textcomponentcontext-template-variables>>).
+|The parent context variables (see xref:using-shell-components-ui-render.adoc#textcomponentcontext-template-variables[TextComponentContext Template Variables]).
 |===

spring-shell-docs/modules/ROOT/pages/using-shell-components-ui.adoc

@@ -19,7 +19,7 @@ Built-in components generally follow this logic:
 . Exit.
 . Render the final status of a component state.
 
-NOTE: <<using-shell-components-flow>> gives better interface for defining the flow of
+NOTE: xref:using-shell-components-flow.adoc[Flow] gives better interface for defining the flow of
 components that are better suited for defining interactive command flows.
 
 

spring-shell-docs/modules/ROOT/pages/using-shell-customization-styling.adoc

@@ -13,7 +13,7 @@ Spring Shell supports these via it's theming framework which contains two parts,
 firstly _styling_ can be used to change text type and secondly _figures_ how
 some characters are shown. These two are then combined together as a _theme_.
 
-More about _theming_ internals, see <<appendix-tech-intro-theming>>.
+More about _theming_ internals, see xref:appendices-techical-intro-theming.adoc[Theming].
 
 NOTE: Default theme is named `default` but can be change using property
 `spring.shell.theme.name`. Other built-in theme named `dump` uses

spring-shell-docs/modules/ROOT/pages/using-shell-execution.adoc

@@ -14,7 +14,7 @@ simple command-line tool without requiring customization.
 
 Currently, interactive mode is entered if any command line options are passed when starting
 or running a shell from a command line. This works especially well when a shell application
-is compiled with <<native>>.
+is compiled with xref:using-shell-building.adoc#native[Native Support].
 
 Some commands may not have any useful meanings when they run in interactive mode
 or (conversely) in non-interactive mode. For example, a built-in `exit` command would

spring-shell-docs/modules/ROOT/pages/using-shell-options-default.adoc

@@ -4,7 +4,7 @@
 ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 Having a default value for an option is somewhat related to
-<<using-shell-options-optional>>, as there are cases where you
+xref:using-shell-options-optional.adoc[Optional Value], as there are cases where you
 may want to know if the user defined an option and change behavior
 based on a default value:
 

spring-shell-docs/modules/ROOT/pages/using-shell-tui-views.adoc

@@ -5,6 +5,6 @@ ifndef::snippets[:snippets: ../../test/java/org/springframework/shell/docs]
 
 Framework provides a build-in views which are documented below.
 
-TIP: To learn more about views, see <<appendix-tui-view>>.
+TIP: To learn more about views, see xref:appendices-tui-view.adoc[View].
 
 

spring-shell-docs/modules/ROOT/pages/using-shell-tui.adoc

@@ -6,9 +6,9 @@ NOTE: Feature is experimental and subject to breaking changes until foundation
 
 _Terminal UI Framework_ is a toolkit to build rich console apps. This section is
 for those using existing features as is. If you're planning to go deeper possibly
-creating your own components <<appendix-tech-intro-tui>> provides more detailed
+creating your own components xref:appendices-tui.adoc[Terminal UI] provides more detailed
 documentation.
 
-TIP: Catalog sample is a good place to study a real application <<appendix-tui-catalog>>.
+TIP: Catalog sample is a good place to study a real application xref:appendices-tui-catalog.adoc[Catalog App].