You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by da...@apache.org on 2019/10/04 06:57:39 UTC

[isis] 04/09: ISIS-2062: fixes some xref's that were missed for rg:cms

This is an automated email from the ASF dual-hosted git repository.

danhaywood pushed a commit to branch ISIS-2062
in repository https://gitbox.apache.org/repos/asf/isis.git

commit fdd90ea0861833678646674743ab4bcf1444f2e0
Author: danhaywood <da...@haywood-associates.co.uk>
AuthorDate: Fri Oct 4 07:18:13 2019 +0100

    ISIS-2062: fixes some xref's that were missed for rg:cms
---
 .../pages/what-is-apache-isis/screencasts.adoc     | 28 +++++++++++-----------
 .../how-run-fixtures-on-app-startup.adoc           |  2 +-
 .../modules/btb/pages/deployment/cmd-line.adoc     |  4 ++--
 .../modules/btb/pages/deployment/docker.adoc       |  2 +-
 .../deployment/externalized-configuration.adoc     |  2 +-
 .../btb/pages/hints-and-tips/are-you-sure.adoc     |  2 +-
 .../how-to-implement-a-spellchecker.adoc           |  2 +-
 .../btb/pages/hints-and-tips/persisted-title.adoc  |  2 +-
 .../btb/pages/hints-and-tips/pushing-changes.adoc  |  4 ++--
 core/_adoc-ug/modules/btb/pages/i18n.adoc          |  6 ++---
 core/_adoc-ug/modules/btb/pages/web-xml.adoc       |  2 +-
 .../building-blocks/events/domain-events.adoc      |  2 +-
 .../types-of-domain-objects/view-models.adoc       |  2 +-
 .../fun/pages/business-rules/side-effects.adoc     |  2 +-
 .../fun/pages/business-rules/usability.adoc        |  4 ++--
 .../modules/fun/pages/business-rules/validity.adoc |  2 +-
 .../fun/pages/business-rules/visibility.adoc       |  2 +-
 .../pages/core-concepts/apache-isis-vs/cqrs.adoc   |  2 +-
 .../apache-isis-vs/event-sourcing.adoc             |  2 +-
 .../modules/fun/pages/drop-downs-and-defaults.adoc |  6 ++---
 .../fun/pages/programming-model/actions.adoc       |  6 ++---
 .../domain-services/registering.adoc               |  2 +-
 .../fun/pages/programming-model/properties.adoc    |  2 +-
 .../programming-model/view-models/non-jaxb.adoc    |  2 +-
 .../fun/pages/ui-hints/action-icons-and-css.adoc   |  4 ++--
 .../pages/ui-hints/object-titles-and-icons.adoc    |  8 +++----
 .../_adoc/modules/ROOT/pages/configuring-core.adoc |  6 ++---
 .../modules/ROOT/pages/specifying-components.adoc  |  2 +-
 .../disabling-persistence-by-reachability.adoc     |  2 +-
 .../modules/ROOT/pages/configuring/properties.adoc |  2 +-
 .../_adoc/modules/ROOT/pages/overview.adoc         |  2 +-
 .../pages/integ-test-support/bootstrapping.adoc    |  2 +-
 .../configuration-properties.adoc                  |  2 +-
 .../pages/integ-test-support/typical-usage.adoc    |  2 +-
 .../_adoc/modules/mvn/pages/intro.adoc             |  4 ++--
 .../pages/unit-test-support/contract-tests.adoc    |  2 +-
 .../hints-and-tips/restful-image-property.adoc     |  2 +-
 .../_adoc/modules/ROOT/pages/layout-resources.adoc |  2 +-
 .../ROOT/pages/features/blob-attachments.adoc      |  2 +-
 .../modules/ROOT/pages/layout/file-based.adoc      | 14 +++++------
 .../ROOT/pages/menubars-layout/file-based.adoc     |  2 +-
 .../simpleapp/_adoc/modules/ROOT/pages/about.adoc  |  2 +-
 42 files changed, 77 insertions(+), 77 deletions(-)

diff --git a/antora/components/toc/modules/ROOT/pages/what-is-apache-isis/screencasts.adoc b/antora/components/toc/modules/ROOT/pages/what-is-apache-isis/screencasts.adoc
index d51b1bf..46e7fb4 100644
--- a/antora/components/toc/modules/ROOT/pages/what-is-apache-isis/screencasts.adoc
+++ b/antora/components/toc/modules/ROOT/pages/what-is-apache-isis/screencasts.adoc
@@ -126,7 +126,7 @@ Using the Swagger UI to access the xref:vro:ROOT:about.adoc[REST API] automatica
 
 
 |link:https://www.youtube.com/watch?v=1sNiR3Y84c0[011^] +
-How the framework uses the xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] is used to bootstrap the application
+How the framework uses the xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] is used to bootstrap the application
 ||||||||||x|
 
 
@@ -159,13 +159,13 @@ include::partial$_screencasts-playlists.adoc[]
 
 
 |link:https://www.youtube.com/watch?v=CwM430UH5WE[014^] +
-Using the xref:rg:cms:methods.adoc#title[`title()`], xref:rg:cms:methods.adoc#iconName[`iconName()`] and xref:rg:cms:methods.adoc#cssClass[`cssClass()`] so that end-users can distinguish domain objects within the UI.
+Using the xref:applib:cms:methods.adoc#title[`title()`], xref:applib:cms:methods.adoc#iconName[`iconName()`] and xref:applib:cms:methods.adoc#cssClass[`cssClass()`] so that end-users can distinguish domain objects within the UI.
 |x||x||||||x||
 
 
 
 |link:https://www.youtube.com/watch?v=7ToRKBOeemM[015^] +
-Moving the responsibility to specify the icon for a domain object out and into a subscriber, using the xref:rg:cms:classes/uievent.adoc#IconUiEvent[`IconUiEvent`] as per the xref:applib:ant:DomainObjectLayout.adoc#iconUiEvent[`@DomainObjectLayout#iconUiEvent()`] annotation
+Moving the responsibility to specify the icon for a domain object out and into a subscriber, using the xref:applib:cms:classes/uievent.adoc#IconUiEvent[`IconUiEvent`] as per the xref:applib:ant:DomainObjectLayout.adoc#iconUiEvent[`@DomainObjectLayout#iconUiEvent()`] annotation
 ||||||x|||||
 
 
@@ -252,13 +252,13 @@ Shows how to refactor a domain object to move (derived) collections out of the d
 
 
 |link:https://www.youtube.com/watch?v=-AQJb9GtIqI[024^] +
-Using a domain event xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscriber] to xref:ug:fun:building-blocks.adoc#domain-events[decouple] and abstract business rules (xref:rg:cms:methods.adoc#validate[validation]).
+Using a domain event xref:applib:cms:classes/super.adoc#AbstractSubscriber[subscriber] to xref:ug:fun:building-blocks.adoc#domain-events[decouple] and abstract business rules (xref:applib:cms:methods.adoc#validate[validation]).
 ||||||x|||||
 
 
 
 |link:https://www.youtube.com/watch?v=6GjLW0hlrm4[025^] +
-Using a domain event xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscriber] to hide functionality, in this
+Using a domain event xref:applib:cms:classes/super.adoc#AbstractSubscriber[subscriber] to hide functionality, in this
   case the xref:rg:cms:rgcms.adoc#__rgcms_classes_mixins_Object_clearHints["clear hints"] action automatically provided by the framework.
 ||||||||||x|
 
@@ -271,7 +271,7 @@ Using a domain event xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscribe
 
 
 |link:https://www.youtube.com/watch?v=qj4bMkQRBUY[026^] +
-Using the xref:applib:ant:Title.adoc[`@Title`] annotation (instead of the xref:rg:cms:methods.adoc#title[`title()`] reserved method) to obtain the title of a domain object, so that the end-user can distinguish one object from another.
+Using the xref:applib:ant:Title.adoc[`@Title`] annotation (instead of the xref:applib:cms:methods.adoc#title[`title()`] reserved method) to obtain the title of a domain object, so that the end-user can distinguish one object from another.
 |x||||||||x||
 
 
@@ -322,7 +322,7 @@ include::partial$_screencasts-playlists.adoc[]
 
 
 |link:https://www.youtube.com/watch?v=ORoEYlg6XFM[030^] +
-How to validate action parameters using a supporting xref:rg:cms:methods.adoc#validate[`validateNXxx()`] method.
+How to validate action parameters using a supporting xref:applib:cms:methods.adoc#validate[`validateNXxx()`] method.
 |x||||||||x||
 
 
@@ -355,19 +355,19 @@ include::partial$_screencasts-playlists.adoc[]
 
 
 |link:https://www.youtube.com/watch?v=cQ06PoMNDPw[033^] +
-How to provide a set of xref:rg:cms:methods.adoc#choices[choices] (a drop-down list) when editing a property.
+How to provide a set of xref:applib:cms:methods.adoc#choices[choices] (a drop-down list) when editing a property.
 |x||||||||x||
 
 
 
 |link:https://www.youtube.com/watch?v=afEnYKljBQs[034^] +
-How to provide a set of xref:rg:cms:methods.adoc#choices[choices] (a drop-down list) when invoking an action.
+How to provide a set of xref:applib:cms:methods.adoc#choices[choices] (a drop-down list) when invoking an action.
 |||||||||x||
 
 
 
 |link:https://www.youtube.com/watch?v=fKo6aTPK-gk[035^] +
-How to use the xref:rg:cms:methods.adoc#choices[choices] supporting methods as a source for default values within a xref:ext-fixtures:ROOT:about.adoc[fixture script].
+How to use the xref:applib:cms:methods.adoc#choices[choices] supporting methods as a source for default values within a xref:ext-fixtures:ROOT:about.adoc[fixture script].
 ||x|||||||x||
 
 
@@ -406,7 +406,7 @@ include::partial$_screencasts-playlists.adoc[]
 
 
 |link:https://www.youtube.com/watch?v=NKaR7ZedI8E[039^] +
-Using the xref:rg:cms:classes/super.adoc#FixtureScript[`FixtureScript`] `defaultParam(...)` method to reflectively default parameters to fixture scripts that have not been set by the caller.
+Using the xref:applib:cms:classes/super.adoc#FixtureScript[`FixtureScript`] `defaultParam(...)` method to reflectively default parameters to fixture scripts that have not been set by the caller.
 ||x|||||||||
 
 
@@ -446,7 +446,7 @@ include::partial$_screencasts-playlists.adoc[]
 
 
 |link:https://www.youtube.com/watch?v=Rt4JoV4ssVY[043^] +
-How to use the supporting xref:rg:cms:methods.adoc#default[`defaultXxx(...)`] supporting method to provide a default argument value for action parameters.
+How to use the supporting xref:applib:cms:methods.adoc#default[`defaultXxx(...)`] supporting method to provide a default argument value for action parameters.
 |x||||||||x||
 
 
@@ -456,12 +456,12 @@ How to use xref:applib:ant:DomainObject.adoc#bounding[`@DomainObject#bounding()`
 
 
 |link:https://www.youtube.com/watch?v=0ro_YhXOpJU[045^] +
-How to use the xref:rg:cms:methods.adoc#choices[`choicesXxx(...)`] supporting method to provide a drop-down list for parameters to actions that are for reference types (domain entities or view models).
+How to use the xref:applib:cms:methods.adoc#choices[`choicesXxx(...)`] supporting method to provide a drop-down list for parameters to actions that are for reference types (domain entities or view models).
 |||||||||x||
 
 
 |link:https://www.youtube.com/watch?v=K36IJQ_hDfs[046^] +
-How to use the xref:rg:cms:methods.adoc#autoComplete[`autoCompleteXxx(...)`] supporting method to provide a drop-down list for parameters to actions that are for reference types (domain entities or view models).
+How to use the xref:applib:cms:methods.adoc#autoComplete[`autoCompleteXxx(...)`] supporting method to provide a drop-down list for parameters to actions that are for reference types (domain entities or view models).
 |||||||||x||
 
 
diff --git a/antora/components/toc/modules/devguide/pages/hints-and-tips/how-run-fixtures-on-app-startup.adoc b/antora/components/toc/modules/devguide/pages/hints-and-tips/how-run-fixtures-on-app-startup.adoc
index ad378e1..061e08c 100644
--- a/antora/components/toc/modules/devguide/pages/hints-and-tips/how-run-fixtures-on-app-startup.adoc
+++ b/antora/components/toc/modules/devguide/pages/hints-and-tips/how-run-fixtures-on-app-startup.adoc
@@ -14,7 +14,7 @@ Use events?_
 
 
 The standard approach is to use xref:ext-fixtures:ROOT:about.adoc[fixture scripts].
-These can be run in on start-up typically by being specified in the xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`], see for example the xref:simpleapp:ROOT:about.adoc[SimpleApp archetype].
+These can be run in on start-up typically by being specified in the xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`], see for example the xref:simpleapp:ROOT:about.adoc[SimpleApp archetype].
 
 Alternatively just set `isis.fixtures` and `isis.persistor.datanucleus.install-fixtures` properties.
 
diff --git a/core/_adoc-ug/modules/btb/pages/deployment/cmd-line.adoc b/core/_adoc-ug/modules/btb/pages/deployment/cmd-line.adoc
index a13b1a3..4f06875 100644
--- a/core/_adoc-ug/modules/btb/pages/deployment/cmd-line.adoc
+++ b/core/_adoc-ug/modules/btb/pages/deployment/cmd-line.adoc
@@ -33,7 +33,7 @@ The class also supports a number of command line arguments:
 |`-m`
 |`--manifest`
 |FQCN
-|Fully qualified class name of the xref:rg:cms:classes/super.adoc#AppManifest[`AppManifest`] to use to bootstrap the system. +
+|Fully qualified class name of the xref:applib:cms:classes/super.adoc#AppManifest[`AppManifest`] to use to bootstrap the system. +
 
 This flag sets/overrides the `isis.appManifest` configuration property to the specified class name.
 
@@ -41,7 +41,7 @@ This flag sets/overrides the `isis.appManifest` configuration property to the sp
 |`-f`
 |`--fixture`
 |FQCN
-|Fully qualified class name of the fixture (extending xref:rg:cms:classes/super.adoc#FixtureScript[`FixtureScript`]) to be run to setup data. +
+|Fully qualified class name of the fixture (extending xref:applib:cms:classes/super.adoc#FixtureScript[`FixtureScript`]) to be run to setup data. +
 
 This flag sets/overrides the `isis.fixtures` configuration property to the specified class name, and also sets the `isis.persistor.datanucleus.install-fixtures` configuration property to `true` to instruct the JDO/DataNucleus objectstore to actually load in the fixtures. +
 
diff --git a/core/_adoc-ug/modules/btb/pages/deployment/docker.adoc b/core/_adoc-ug/modules/btb/pages/deployment/docker.adoc
index e931f8d..e0e120a 100644
--- a/core/_adoc-ug/modules/btb/pages/deployment/docker.adoc
+++ b/core/_adoc-ug/modules/btb/pages/deployment/docker.adoc
@@ -21,7 +21,7 @@ Docker host can be assured.
 == Using an `overrides.properties`
 
 In addition to loading the regular configuration properties from `WEB-INF` directory (described
-xref:rg:cfg:configuration-files.adoc[here]), Apache Isis will also load the `overrides.properties` file.
+xref:cfg:ROOT:configuration-files.adoc[here]), Apache Isis will also load the `overrides.properties` file.
 
 This file is treated slightly differently than the other configuration files; it is loaded last, and any configuration
 properties defined in it will _override_ any configuration properties already read from other files (this includes
diff --git a/core/_adoc-ug/modules/btb/pages/deployment/externalized-configuration.adoc b/core/_adoc-ug/modules/btb/pages/deployment/externalized-configuration.adoc
index f0a35d7..96835e5 100644
--- a/core/_adoc-ug/modules/btb/pages/deployment/externalized-configuration.adoc
+++ b/core/_adoc-ug/modules/btb/pages/deployment/externalized-configuration.adoc
@@ -6,7 +6,7 @@ include::_attributes.adoc[]
 
 
 
-As described xref:rg:cfg:configuration-files.adoc[here], by default Apache Isis itself bootstraps from the
+As described xref:cfg:ROOT:configuration-files.adoc[here], by default Apache Isis itself bootstraps from the
 `isis.properties` configuration file.
 It will also read configuration from the (optional) component/implementation-specific configuration files (such as `persistor_datanucleus.properties` or `viewer_wicket.properties`), and also (optional) component-specific configuration files (such as `persistor.properties` or `viewer.properties`).
 
diff --git a/core/_adoc-ug/modules/btb/pages/hints-and-tips/are-you-sure.adoc b/core/_adoc-ug/modules/btb/pages/hints-and-tips/are-you-sure.adoc
index b424802..cda37a8 100644
--- a/core/_adoc-ug/modules/btb/pages/hints-and-tips/are-you-sure.adoc
+++ b/core/_adoc-ug/modules/btb/pages/hints-and-tips/are-you-sure.adoc
@@ -72,4 +72,4 @@ public String validateDelete(boolean areYouSure) {
 ----
 <1> invalid to return `this` (cannot render a deleted object)
 
-Note that the action itself does not use the boolean parameter, it is only used by the supporting xref:rg:cms:methods.adoc#validate[`validate...()`] method.
\ No newline at end of file
+Note that the action itself does not use the boolean parameter, it is only used by the supporting xref:applib:cms:methods.adoc#validate[`validate...()`] method.
\ No newline at end of file
diff --git a/core/_adoc-ug/modules/btb/pages/hints-and-tips/how-to-implement-a-spellchecker.adoc b/core/_adoc-ug/modules/btb/pages/hints-and-tips/how-to-implement-a-spellchecker.adoc
index a02da1c..e7a80fd 100644
--- a/core/_adoc-ug/modules/btb/pages/hints-and-tips/how-to-implement-a-spellchecker.adoc
+++ b/core/_adoc-ug/modules/btb/pages/hints-and-tips/how-to-implement-a-spellchecker.adoc
@@ -13,7 +13,7 @@ From this link:http://isis.markmail.org/thread/dduarjscrbnodfsi[thread] on the A
 
 One way to implement is to use the xref:applib:svc:core-domain-api/EventBusService.adoc[event bus]:
 
-* Set up a xref:rg:cms:classes/domainevent.adoc[domain event] xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscriber] that can veto the changes.
+* Set up a xref:applib:cms:classes/domainevent.adoc[domain event] xref:applib:cms:classes/super.adoc#AbstractSubscriber[subscriber] that can veto the changes.
 
 * if the change is made through an action, you can use xref:applib:ant:Action.adoc#domainEvent[`@Action#domainEvent()`].
 
diff --git a/core/_adoc-ug/modules/btb/pages/hints-and-tips/persisted-title.adoc b/core/_adoc-ug/modules/btb/pages/hints-and-tips/persisted-title.adoc
index b00b703..edc4ab3 100644
--- a/core/_adoc-ug/modules/btb/pages/hints-and-tips/persisted-title.adoc
+++ b/core/_adoc-ug/modules/btb/pages/hints-and-tips/persisted-title.adoc
@@ -8,7 +8,7 @@ include::_attributes.adoc[]
 
 Normally the title of an object is not persisted to the database, rather it is recomputed automatically from underlying properties.  On occasion though you might want the title to also be persisted; either to make things easier for the DBA, or for an integration scenario, or some other purpose.
 
-We can implement this feature by leveraging the xref:rg:cms:methods.adoc#jdo-api[JDO lifecycle].  In the design we discuss here we make it a responsibility of the entities to persist the title as a property, by implementing a `ObjectWithPersistedTitle` interface:
+We can implement this feature by leveraging the xref:applib:cms:methods.adoc#jdo-api[JDO lifecycle].  In the design we discuss here we make it a responsibility of the entities to persist the title as a property, by implementing a `ObjectWithPersistedTitle` interface:
 
 [source,java]
 ----
diff --git a/core/_adoc-ug/modules/btb/pages/hints-and-tips/pushing-changes.adoc b/core/_adoc-ug/modules/btb/pages/hints-and-tips/pushing-changes.adoc
index cb84cc0..0ea7b26 100644
--- a/core/_adoc-ug/modules/btb/pages/hints-and-tips/pushing-changes.adoc
+++ b/core/_adoc-ug/modules/btb/pages/hints-and-tips/pushing-changes.adoc
@@ -134,7 +134,7 @@ public class Department {
 --
 <1> maintain a count of the number of male ...
 <2> ... and female employees (getters and setters omitted)
-<3> the xref:rg:cms:methods.adoc#addTo[`addTo...()`] method increments the derived properties
-<4> the xref:rg:cms:methods.adoc#removeFrom[`removeFrom...()`] method similarly decrements the derived properties
+<3> the xref:applib:cms:methods.adoc#addTo[`addTo...()`] method increments the derived properties
+<4> the xref:applib:cms:methods.adoc#removeFrom[`removeFrom...()`] method similarly decrements the derived properties
 
 
diff --git a/core/_adoc-ug/modules/btb/pages/i18n.adoc b/core/_adoc-ug/modules/btb/pages/i18n.adoc
index b0127a0..4c734bd 100644
--- a/core/_adoc-ug/modules/btb/pages/i18n.adoc
+++ b/core/_adoc-ug/modules/btb/pages/i18n.adoc
@@ -7,7 +7,7 @@ include::_attributes.adoc[]
 
 Apache Isis' support for internationlization (i18n) allows every element of the domain model (the class names, property names, action names, parameter names and so forth) to be translated.
 
-It also supports translations of messages raised imperatively, by which we mean as the result of a call to `title()` to obtain an object's title, or messages resulting from any business rule violations (eg xref:rg:cms:methods.adoc#disable[`disable...()`] or xref:rg:cms:methods.adoc#validate[`validate...()`], and so on.
+It also supports translations of messages raised imperatively, by which we mean as the result of a call to `title()` to obtain an object's title, or messages resulting from any business rule violations (eg xref:applib:cms:methods.adoc#disable[`disable...()`] or xref:applib:cms:methods.adoc#validate[`validate...()`], and so on.
 
 The xref:vw:ROOT:about.adoc[Wicket viewer] (that is, its labels and messages) is also internationalized using the same mechanism.
 If no translations are available, then the Wicket viewer falls back to using Wicket resource bundles.
@@ -105,9 +105,9 @@ All requested translations are written into the `.pot` file.
 
 To make the service as convenient as possible to use, the service configures itself as follows:
 
-* if running in prototype mode xref:rg:cfg:deployment-types.adoc[deployment type] or during integration tests, then the service runs in *write* mode, in which case it records all translations into the `.pot` file.
+* if running in prototype mode xref:cfg:ROOT:deployment-types.adoc[deployment type] or during integration tests, then the service runs in *write* mode, in which case it records all translations into the `.pot` file.
 The `.pot` file is written out when the system is shutdown.
-* if running in server (production) mode xref:rg:cfg:deployment-types.adoc[deployment type], then the service runs in *read* mode.
+* if running in server (production) mode xref:cfg:ROOT:deployment-types.adoc[deployment type], then the service runs in *read* mode.
 It is also possible to set a configuration setting in `isis.properties` to force read mode even if running in prototype mode (useful to manually test/demo the translations).
 
 When running in write mode the original text is returned to the caller untranslated.
diff --git a/core/_adoc-ug/modules/btb/pages/web-xml.adoc b/core/_adoc-ug/modules/btb/pages/web-xml.adoc
index 1561428..e799bf6 100644
--- a/core/_adoc-ug/modules/btb/pages/web-xml.adoc
+++ b/core/_adoc-ug/modules/btb/pages/web-xml.adoc
@@ -388,7 +388,7 @@ This filter reads one context parameter:
     <param-value>deployment</param-value>   <!--1-->
 </context-param>
 ----
-<1> alternatively set to "development"; see xref:rg:cfg:deployment-types.adoc[deployment types] for further discussion.
+<1> alternatively set to "development"; see xref:cfg:ROOT:deployment-types.adoc[deployment types] for further discussion.
 
 
 === `IsisSessionFilter`
diff --git a/core/_adoc-ug/modules/fun/pages/building-blocks/events/domain-events.adoc b/core/_adoc-ug/modules/fun/pages/building-blocks/events/domain-events.adoc
index 12085b8..67fad24 100644
--- a/core/_adoc-ug/modules/fun/pages/building-blocks/events/domain-events.adoc
+++ b/core/_adoc-ug/modules/fun/pages/building-blocks/events/domain-events.adoc
@@ -32,7 +32,7 @@ For example, a cascade delete could be implemented here.
 For example, a business audit event could be implemented here.
 
 
-For more details on the actual domain event classes, see the xref:rg:cms:classes/domainevent.adoc[domain event] section of the relevant reference guide.
+For more details on the actual domain event classes, see the xref:applib:cms:classes/domainevent.adoc[domain event] section of the relevant reference guide.
 
 
 
diff --git a/core/_adoc-ug/modules/fun/pages/building-blocks/types-of-domain-objects/view-models.adoc b/core/_adoc-ug/modules/fun/pages/building-blocks/types-of-domain-objects/view-models.adoc
index 77c7bf7..d6e842a 100644
--- a/core/_adoc-ug/modules/fun/pages/building-blocks/types-of-domain-objects/view-models.adoc
+++ b/core/_adoc-ug/modules/fun/pages/building-blocks/types-of-domain-objects/view-models.adoc
@@ -115,7 +115,7 @@ In case it's not obvious, these DTOs are still usable as "regular" view models;
 In fact (as the xref:ug:fun:programming-model.adoc#jaxb[programming model] section below makes clear), these JAXB-annotated view models are in many regards the most powerful of all the alternative ways of writing view models.
 
 It's also worth noting that it is also possible to download the XML (or XSD) straight from the UI, useful during development.
-The view model simply needs to implement the xref:rg:cms:classes/mixins.adoc#Dto[`Dto`] marker interface; the framework has xref:rg:cms:classes/mixins.adoc#Dto[mixins] that contribute the download actions to the view model.
+The view model simply needs to implement the xref:applib:cms:classes/mixins.adoc#Dto[`Dto`] marker interface; the framework has xref:applib:cms:classes/mixins.adoc#Dto[mixins] that contribute the download actions to the view model.
 
 [TIP]
 ====
diff --git a/core/_adoc-ug/modules/fun/pages/business-rules/side-effects.adoc b/core/_adoc-ug/modules/fun/pages/business-rules/side-effects.adoc
index d52bbc0..d6c9a5a 100644
--- a/core/_adoc-ug/modules/fun/pages/business-rules/side-effects.adoc
+++ b/core/_adoc-ug/modules/fun/pages/business-rules/side-effects.adoc
@@ -46,6 +46,6 @@ Datanucleus does _not_ call the setter when reloading the object from the databa
 
 [NOTE]
 ====
-The framework also allows side-effect code to be placed in separate xref:rg:cms:methods.adoc#modify[`modify...()`], xref:rg:cms:methods.adoc#clear[`clear...()`] supporting methods; if present then these will be called by the framework rather than the setter.
+The framework also allows side-effect code to be placed in separate xref:applib:cms:methods.adoc#modify[`modify...()`], xref:applib:cms:methods.adoc#clear[`clear...()`] supporting methods; if present then these will be called by the framework rather than the setter.
 However, because of DataNucleus' smart handling of setters, these supporting methods are in essence redundant, and so should be considered deprecated.
 ====
diff --git a/core/_adoc-ug/modules/fun/pages/business-rules/usability.adoc b/core/_adoc-ug/modules/fun/pages/business-rules/usability.adoc
index 8082aa6..f71ba87 100644
--- a/core/_adoc-ug/modules/fun/pages/business-rules/usability.adoc
+++ b/core/_adoc-ug/modules/fun/pages/business-rules/usability.adoc
@@ -29,7 +29,7 @@ To make _all_ of the properties of a domain object unmodifiable, use:
 public class Customer { /* ... */ }
 ----
 
-This can be made a global policy using a xref:rg:cfg:configuring-core.adoc#isis-objects-editing[configuration setting]:
+This can be made a global policy using a xref:cfg:ROOT:configuring-core.adoc#isis-objects-editing[configuration setting]:
 
 .isis.properties
 [source,ini]
@@ -75,7 +75,7 @@ public String disable1Categorize(Category category) {
 
 == For more information
 
-For more information, see  xref:rg:cms:methods.adoc#disable[`disable...()`] section in the appropriate reference guide.
+For more information, see  xref:applib:cms:methods.adoc#disable[`disable...()`] section in the appropriate reference guide.
 
 
 It is also possible to hide an action parameter, based on the value of some other earlier parameter:
diff --git a/core/_adoc-ug/modules/fun/pages/business-rules/validity.adoc b/core/_adoc-ug/modules/fun/pages/business-rules/validity.adoc
index 1a788f1..c493f82 100644
--- a/core/_adoc-ug/modules/fun/pages/business-rules/validity.adoc
+++ b/core/_adoc-ug/modules/fun/pages/business-rules/validity.adoc
@@ -43,7 +43,7 @@ It is also possible to return a localized string by returning a `TranslatableStr
 
 == For more information
 
-For more information, see the xref:rg:cms:methods.adoc#validate[`validate...()`] section in the appropriate reference guide.
+For more information, see the xref:applib:cms:methods.adoc#validate[`validate...()`] section in the appropriate reference guide.
 The reference guide also explains how to define validation declaratively, using the xref:applib:ant:Parameter.adoc#mustSatisfy[`@Parameter#mustSatisfy()`] or xref:applib:ant:Property.adoc#mustSatisfy[`@Property#mustSatisfy()`] attributes.
 
 
diff --git a/core/_adoc-ug/modules/fun/pages/business-rules/visibility.adoc b/core/_adoc-ug/modules/fun/pages/business-rules/visibility.adoc
index 3bf30d6..871a9bf 100644
--- a/core/_adoc-ug/modules/fun/pages/business-rules/visibility.adoc
+++ b/core/_adoc-ug/modules/fun/pages/business-rules/visibility.adoc
@@ -62,7 +62,7 @@ However, if they check the first boolean parameter (ie, to ship the `Order` to t
 
 == For more information
 
-For more information, see the xref:rg:cms:methods.adoc#hide[`hide...()`] section in the appropriate reference guide.
+For more information, see the xref:applib:cms:methods.adoc#hide[`hide...()`] section in the appropriate reference guide.
 
 
 
diff --git a/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/cqrs.adoc b/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/cqrs.adoc
index e6201a0..37d9ea9 100644
--- a/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/cqrs.adoc
+++ b/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/cqrs.adoc
@@ -31,7 +31,7 @@ There are other reasons though why a separate read model might make sense, such
 In these cases Apache Isis can often provide a reasonable alternative, namely to map domain entities against RDBMS views, either materialized views or dynamic.
 In such cases there is still only a single physical datastore, and so transactional integrity is retained.
 
-Or, the CQRS architecture can be more fully implemented with Apache Isis by introducing a separate read model, synchronized using the xref:applib:svc:persistence-layer-spi/PublisherService.adoc[`PublisherService`], or using xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscribers]  on the xref:applib:svc:core-domain-api/EventBusService.adoc[`EventBusService`].
+Or, the CQRS architecture can be more fully implemented with Apache Isis by introducing a separate read model, synchronized using the xref:applib:svc:persistence-layer-spi/PublisherService.adoc[`PublisherService`], or using xref:applib:cms:classes/super.adoc#AbstractSubscriber[subscribers]  on the xref:applib:svc:core-domain-api/EventBusService.adoc[`EventBusService`].
 One can then use xref:ug:fun:building-blocks.adoc#view-models[view models] to surface the data in the external read datastore.
 
 With respect to commands, Apache Isis does of course support the xref:applib:svc:application-layer-spi/CommandService.adoc[`CommandService`] which allows each business action to be reified into a `Command`.
diff --git a/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/event-sourcing.adoc b/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/event-sourcing.adoc
index d45c0fb..0a07b14 100644
--- a/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/event-sourcing.adoc
+++ b/core/_adoc-ug/modules/fun/pages/core-concepts/apache-isis-vs/event-sourcing.adoc
@@ -23,7 +23,7 @@ If the latter, then the subscriber will operate within a separate transaction, m
 CQRS/event sourcing advocates point out -- correctly -- that this is just how things are in the "real world" too.
 
 In Apache Isis every business action (and indeed, property and collection) emits domain events through the xref:applib:svc:core-domain-api/EventBusService.adoc[`EventBusService`], and can optionally also be published through the xref:applib:svc:persistence-layer-spi/PublisherService.adoc[`PublisherService`].
-The former are dispatched and consumed in-process and within the same transaction, and for this reason the xref:rg:cms:classes/super.adoc#AbstractSubscriber[subscribers] can also veto the events.
+The former are dispatched and consumed in-process and within the same transaction, and for this reason the xref:applib:cms:classes/super.adoc#AbstractSubscriber[subscribers] can also veto the events.
 The latter are intended for out-of-process consumption; the (obsolete) http://github.com/isisaddons-legacy/isis-module-publishing[Isis addons' publishing] and the (non-ASF) link:https://platform.incode.org[Incode Platform^]'s publishmq modules provide implementations for dispatching either through a RDBMS database table, or directly through to an link:http://camel.apache.org[ActiveMQ] message queue (eg wired up to link:http://camel.apache.org[Apache Camel] event bus).
 
 
diff --git a/core/_adoc-ug/modules/fun/pages/drop-downs-and-defaults.adoc b/core/_adoc-ug/modules/fun/pages/drop-downs-and-defaults.adoc
index c17e19f..9c3cbfe 100644
--- a/core/_adoc-ug/modules/fun/pages/drop-downs-and-defaults.adoc
+++ b/core/_adoc-ug/modules/fun/pages/drop-downs-and-defaults.adoc
@@ -7,16 +7,16 @@ include::_attributes.adoc[]
 Invoking an action whose parameters are primitives or values (int, date, string etc) is simple: the user can just type in or use a date picker.
 Invoking an action with a parameter of reference type (such as `Customer` or `Order`) requires the viewer to provide some mechanism by which the end-user can select the relevant instance.
 
-If the list of available options is fixed then the developer can provided a list a xref:rg:cms:methods.adoc#choices[`choices...()`] supporting method (for either and action parameter or when editing a property).
+If the list of available options is fixed then the developer can provided a list a xref:applib:cms:methods.adoc#choices[`choices...()`] supporting method (for either and action parameter or when editing a property).
 These are rendered in a drop-down.
 
-If the list of available options is much larger, then the developer can use an xref:rg:cms:methods.adoc#autoComplete[`autoComplete...()`] supporting method.
+If the list of available options is much larger, then the developer can use an xref:applib:cms:methods.adoc#autoComplete[`autoComplete...()`] supporting method.
 The user user enters a few characters and this is used to search for matching reference(s), again rendered in a drop-down.
 
 Similarly, when invoking an action, there may well be suitable defaults for the action arguments.
 For example, if placing an `Order` then -- even if the `Product` argument might not have a sensible default -- the quantity argument could reasonably be defaulted to 1.
 Or, the `Product` might indeed have a default, say the product previously placed by this user.
-The developer indicates this using a xref:rg:cms:methods.adoc#default[`default...()`] supporting method.
+The developer indicates this using a xref:applib:cms:methods.adoc#default[`default...()`] supporting method.
 
 
 == Choices and Default
diff --git a/core/_adoc-ug/modules/fun/pages/programming-model/actions.adoc b/core/_adoc-ug/modules/fun/pages/programming-model/actions.adoc
index 66e6deb..1f1fc55 100644
--- a/core/_adoc-ug/modules/fun/pages/programming-model/actions.adoc
+++ b/core/_adoc-ug/modules/fun/pages/programming-model/actions.adoc
@@ -23,7 +23,7 @@ But if the state change is more complex, then most likely an action should be us
 
 == Defining actions
 
-If the xref:rg:cfg:configuring-core.adoc#policy[`isis.reflector.explicitAnnotations.action`] configuration property is set (recommended), then actions are `public` methods with the xref:applib:ant:Action.adoc[`@Action`] annotation.
+If the xref:cfg:ROOT:configuring-core.adoc#policy[`isis.reflector.explicitAnnotations.action`] configuration property is set (recommended), then actions are `public` methods with the xref:applib:ant:Action.adoc[`@Action`] annotation.
 This annotation can also specify additional domain semantics, for example regarding idempotency.
 
 For example:
@@ -46,7 +46,7 @@ public ShoppingBasket addToBasket(
 For the `product` parameter this is reasonable, but not so for the `quantity` parameter (which would by default show up with a name of "int".
 The `@ParameterLayout` annotation provides a UI hint to the framework.
 
-If the xref:rg:cfg:configuring-core.adoc#policy[`isis.reflector.explicitAnnotations.action`] configuration property is _not_ set, then the rules are a little more involved: an action is a public method that is not getters or setters which represent properties or collections, and does not have one of the various method prefixes (such as `hide` or `validate`) used for represent xref:ug:fun:business-rules.adoc[business rules]), and is not annotated with xref:applib:ant:Programmatic.adoc[`@P [...]
+If the xref:cfg:ROOT:configuring-core.adoc#policy[`isis.reflector.explicitAnnotations.action`] configuration property is _not_ set, then the rules are a little more involved: an action is a public method that is not getters or setters which represent properties or collections, and does not have one of the various method prefixes (such as `hide` or `validate`) used for represent xref:ug:fun:business-rules.adoc[business rules]), and is not annotated with xref:applib:ant:Programmatic.adoc[` [...]
 
 
 
@@ -56,7 +56,7 @@ If the xref:rg:cfg:configuring-core.adoc#policy[`isis.reflector.explicitAnnotati
 Parameter types can be value types or reference types.
 In the case of primitive types, the end-user can just enter the value directly through the parameter field.
 In the case of reference types however (such as `Product`), a drop-down must be provided from which the end-user to select.
-This is done using either a supporting xref:rg:cms:methods.adoc#choices[`choices`] or xref:rg:cms:methods.adoc#autoComplete[`autoComplete`] method.
+This is done using either a supporting xref:applib:cms:methods.adoc#choices[`choices`] or xref:applib:cms:methods.adoc#autoComplete[`autoComplete`] method.
 The "choices" is used when there is a limited set of options, while "autoComplete" is used when there are large set of options such that the end-user must provide some characters to use for a search.
 
 For example, the `addToBasket(...)` action shown above might well have an autocomplete supporting method :
diff --git a/core/_adoc-ug/modules/fun/pages/programming-model/domain-services/registering.adoc b/core/_adoc-ug/modules/fun/pages/programming-model/domain-services/registering.adoc
index 124123b..ce36e18 100644
--- a/core/_adoc-ug/modules/fun/pages/programming-model/domain-services/registering.adoc
+++ b/core/_adoc-ug/modules/fun/pages/programming-model/domain-services/registering.adoc
@@ -7,7 +7,7 @@ include::_attributes.adoc[]
 // TODO: v2: this is out of date, need to xref Spring Boot mechanism instead.
 
 
-The easiest way to register domain services with the framework is to use an xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`].
+The easiest way to register domain services with the framework is to use an xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`].
 This specifies the modules which contain xref:applib:ant:DomainService.adoc[`@DomainService`]-annotated classes.
 
 For example:
diff --git a/core/_adoc-ug/modules/fun/pages/programming-model/properties.adoc b/core/_adoc-ug/modules/fun/pages/programming-model/properties.adoc
index d507140..a83315c 100644
--- a/core/_adoc-ug/modules/fun/pages/programming-model/properties.adoc
+++ b/core/_adoc-ug/modules/fun/pages/programming-model/properties.adoc
@@ -119,7 +119,7 @@ For example:
 private String notes;
 ----
 
-If this is omitted then whether editing is enabled or disabled is defined globally, in the `isis.properties` configuration file; see xref:rg:cfg:configuring-core.adoc#isis-objects-editing[reference configuration guide] for further details.
+If this is omitted then whether editing is enabled or disabled is defined globally, in the `isis.properties` configuration file; see xref:cfg:ROOT:configuring-core.adoc#isis-objects-editing[reference configuration guide] for further details.
 
 
 == Ignoring Properties
diff --git a/core/_adoc-ug/modules/fun/pages/programming-model/view-models/non-jaxb.adoc b/core/_adoc-ug/modules/fun/pages/programming-model/view-models/non-jaxb.adoc
index a97d3e6..c5b4f78 100644
--- a/core/_adoc-ug/modules/fun/pages/programming-model/view-models/non-jaxb.adoc
+++ b/core/_adoc-ug/modules/fun/pages/programming-model/view-models/non-jaxb.adoc
@@ -69,7 +69,7 @@ public class ExcelUploadManager implements ViewModel {
   public void viewModelInit(String memento) { /* ... */ }
 }
 ----
-|Implement xref:rg:cms:classes/super.adoc#ViewModel[`ViewModel`] interface.  The memento is as defined by the
+|Implement xref:applib:cms:classes/super.adoc#ViewModel[`ViewModel`] interface.  The memento is as defined by the
 interface's methods: the programmer has full control (but also full responsibility) for the string memento.
 
 |===
diff --git a/core/_adoc-ug/modules/fun/pages/ui-hints/action-icons-and-css.adoc b/core/_adoc-ug/modules/fun/pages/ui-hints/action-icons-and-css.adoc
index 7222875..974fcf8 100644
--- a/core/_adoc-ug/modules/fun/pages/ui-hints/action-icons-and-css.adoc
+++ b/core/_adoc-ug/modules/fun/pages/ui-hints/action-icons-and-css.adoc
@@ -35,7 +35,7 @@ Alternatively, you can specify these hints dynamically in the xref:vw:ROOT:layou
 Rather than annotating every action with xref:applib:ant:ActionLayout.adoc#cssClassFa[`@ActionLayout#cssClassFa()`] and xref:applib:ant:ActionLayout.adoc#cssClass[`@ActionLayout#cssClass()`] you can instead specify the UI hint globally using regular expressions.
 Not only does this save a lot of boilerplate/editing, it helps ensure consistency across all actions.
 
-To declare fa classes globally, use the xref:rg:cfg:configuring-core.adoc[configuration property] `isis.reflector.facet.cssClassFa.patterns` (a comma separated list of key:value pairs).
+To declare fa classes globally, use the xref:cfg:ROOT:configuring-core.adoc[configuration property] `isis.reflector.facet.cssClassFa.patterns` (a comma separated list of key:value pairs).
 
 For example:
 
@@ -78,7 +78,7 @@ Again, this CSS class will be attached to an appropriate containing `<div>` or `
 Possible use cases for this is to highlight the most important properties of a domain object.
 
 
-It is also possible to specify CSS classes globally, using the xref:rg:cfg:configuring-core.adoc[configuration property] `isis.reflector.facet.cssClass.patterns` configuration property.
+It is also possible to specify CSS classes globally, using the xref:cfg:ROOT:configuring-core.adoc[configuration property] `isis.reflector.facet.cssClass.patterns` configuration property.
 
 For example:
 
diff --git a/core/_adoc-ug/modules/fun/pages/ui-hints/object-titles-and-icons.adoc b/core/_adoc-ug/modules/fun/pages/ui-hints/object-titles-and-icons.adoc
index 3d47349..daee8a5 100644
--- a/core/_adoc-ug/modules/fun/pages/ui-hints/object-titles-and-icons.adoc
+++ b/core/_adoc-ug/modules/fun/pages/ui-hints/object-titles-and-icons.adoc
@@ -88,7 +88,7 @@ could return "Arthur C. Clarke".
 
 === Imperative style
 
-Alternatively, the title can be provided simply by implementing the xref:rg:cms:methods.adoc#title[`title()`] reserved method.
+Alternatively, the title can be provided simply by implementing the xref:applib:cms:methods.adoc#title[`title()`] reserved method.
 
 For example:
 
@@ -191,7 +191,7 @@ public class InvoiceRun {
 
 === Imperative style
 
-To customise the icon on an instance-by-instance basis, we implement the reserved xref:rg:cms:methods.adoc#iconName[`iconName()`] method.
+To customise the icon on an instance-by-instance basis, we implement the reserved xref:applib:cms:methods.adoc#iconName[`iconName()`] method.
 
 For example:
 
@@ -257,7 +257,7 @@ public class OrderSubscriptions extends AbstractSubscriber {
 
 == Object CSS Styling
 
-It is also possible for an object to return a xref:rg:cms:methods.adoc#cssClass[CSS class].
+It is also possible for an object to return a xref:applib:cms:methods.adoc#cssClass[CSS class].
 In conjunction with xref:vw:ROOT:customisation/tweaking-css-classes.adoc[customized CSS] this can be used to apply arbitrary styling; for example each object could be rendered in a page with a different background colour.
 
 
@@ -277,7 +277,7 @@ One possible use case would be to render the most important object types with a
 === Imperative style
 
 
-To customise the icon on an instance-by-instance basis, we implement the reserved xref:rg:cms:methods.adoc#cssClass[`cssClass()`] method.
+To customise the icon on an instance-by-instance basis, we implement the reserved xref:applib:cms:methods.adoc#cssClass[`cssClass()`] method.
 
 For example:
 
diff --git a/core/config/_adoc/modules/ROOT/pages/configuring-core.adoc b/core/config/_adoc/modules/ROOT/pages/configuring-core.adoc
index b38719b..798f0cf 100644
--- a/core/config/_adoc/modules/ROOT/pages/configuring-core.adoc
+++ b/core/config/_adoc/modules/ROOT/pages/configuring-core.adoc
@@ -231,7 +231,7 @@ In order for these events to fire the class must be annotated using `@DomainObje
 
 |`isis.services`
 |`FQCN`,`FQCN2`,...
-|NO LONGER REQUIRED; replaced by xref:rg:cms:classes/super.adoc#AppManifest[`AppManifest`].
+|NO LONGER REQUIRED; replaced by xref:applib:cms:classes/super.adoc#AppManifest[`AppManifest`].
 
 (It used to define the list of fully qualified class names of classes to be instantiated as domain services; this is now inferred from the list of modules provided to the app manifest).
 
@@ -309,7 +309,7 @@ If the setting is changed to disabled then this may reduce application start-up
 `packagePrefix`
 |fully qualified package names (CSV)
 
-|NO LONGER REQUIRED; replaced by xref:rg:cms:classes/super.adoc#AppManifest[`AppManifest`].
+|NO LONGER REQUIRED; replaced by xref:applib:cms:classes/super.adoc#AppManifest[`AppManifest`].
 
 (It used to define the list of packages to search for domain services; ; this is now inferred from the list of modules provided to the app manifest).
 
@@ -511,7 +511,7 @@ This is by way of possibly deprecating and eventually moving contributed service
 `noParamsOnly`
 |`true`,`false` +
 (`false`)
-| When searching for  xref:rg:cms:methods.adoc#disable[`disableXxx()`] or xref:rg:cms:methods.adoc#hide[`hideXxx()`] methods, whether to search only for the no-param version (or also for supporting methods that match the parameter types of the action). +
+| When searching for  xref:applib:cms:methods.adoc#disable[`disableXxx()`] or xref:applib:cms:methods.adoc#hide[`hideXxx()`] methods, whether to search only for the no-param version (or also for supporting methods that match the parameter types of the action). +
 
 If enabled then will not search for supporting methods with the exact set of arguments as the method it was supporting (and any supporting methods that have additional parameters will be treated as invalid).
 Note that this in effect means that xref:ug:fun:building-blocks.adoc#mixins[mixins] must be used instead of xref:ug:fun:programming-model.adoc#contributions[contributed services].
diff --git a/core/config/_adoc/modules/ROOT/pages/specifying-components.adoc b/core/config/_adoc/modules/ROOT/pages/specifying-components.adoc
index f4ac045..d12a305 100644
--- a/core/config/_adoc/modules/ROOT/pages/specifying-components.adoc
+++ b/core/config/_adoc/modules/ROOT/pages/specifying-components.adoc
@@ -11,7 +11,7 @@ Bootstrapping an Apache Isis application involves identifying both:
 * the major components (authentication, persistence mechanisms, viewers) of Apache Isis, and also
 * specifying the domain services and persistent entities that make up the application itself.
 
-This is done using an xref:rg:cms:classes/super.adoc#AppManifest[`AppManifest`], specified either programmatically or through the configuration properties.
+This is done using an xref:applib:cms:classes/super.adoc#AppManifest[`AppManifest`], specified either programmatically or through the configuration properties.
 This allows the components, services and entities to be specified from a single class.
 
 To specify the `AppManifest` as a configuration property, use:
diff --git a/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/disabling-persistence-by-reachability.adoc b/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/disabling-persistence-by-reachability.adoc
index 3e49ab6..b084cd6 100644
--- a/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/disabling-persistence-by-reachability.adoc
+++ b/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/disabling-persistence-by-reachability.adoc
@@ -15,7 +15,7 @@ DataNucleus' persistence-by-reachability may cause performance issues.
 We strongly recommend that you disable it.
 ====
 
-One scenario in particular where this performance issues can arise is if your entities implement the `java.lang.Comparable` interface, and you have used Apache Isis' xref:rg:cms:classes/utility.adoc#ObjectContracts[`ObjectContracts`] utility class.
+One scenario in particular where this performance issues can arise is if your entities implement the `java.lang.Comparable` interface, and you have used Apache Isis' xref:applib:cms:classes/utility.adoc#ObjectContracts[`ObjectContracts`] utility class.
 The issue here is that `ObjectContracts` implementation can cause DataNucleus to recursively rehydrate a larger number of associated entities.
 (More detail below).
 
diff --git a/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/properties.adoc b/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/properties.adoc
index 2f94e02..f8c02ed 100644
--- a/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/properties.adoc
+++ b/core/plugins/jdo/_adoc/modules/ROOT/pages/configuring/properties.adoc
@@ -42,7 +42,7 @@ There generally is no need to change this from its default.
 `RegisterEntities.` +
 `packagePrefix`
 |fully qualified package names, CSV
-|This property is derived automatically derived from the set of modules provided in the xref:rg:cms:classes/super.adoc#AppManifest[`AppManifest`], and so does not need to be specified explicitly.
+|This property is derived automatically derived from the set of modules provided in the xref:applib:cms:classes/super.adoc#AppManifest[`AppManifest`], and so does not need to be specified explicitly.
 
 It holds the set of packages to search so that DataNucleus builds its metamodel eagerly rather than lazily.
 
diff --git a/core/testsupport/_adoc/modules/ROOT/pages/overview.adoc b/core/testsupport/_adoc/modules/ROOT/pages/overview.adoc
index 0a59f5d..cacd314 100644
--- a/core/testsupport/_adoc/modules/ROOT/pages/overview.adoc
+++ b/core/testsupport/_adoc/modules/ROOT/pages/overview.adoc
@@ -123,7 +123,7 @@ In the previous section we discussed using given/when/then as a form of organizi
 
 For integration tests though it can be difficult to keep the "given" short; there could be a lot of prerequisite data that needs to exist before you can actually exercise your system.  Moreover, however we do set up that data, but we also want to do so in a way that is resilient to the system changing over time.
 
-The solution that Apache Isis provides is a domain service called xref:rg:cms:classes/super.adoc#FixtureScripts[Fixture Scripts], that defines a pattern and supporting classes to help ensure that the "data setup" for your tests are reusable and maintainable over time.
+The solution that Apache Isis provides is a domain service called xref:applib:cms:classes/super.adoc#FixtureScripts[Fixture Scripts], that defines a pattern and supporting classes to help ensure that the "data setup" for your tests are reusable and maintainable over time.
 
 
 
diff --git a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/bootstrapping.adoc b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/bootstrapping.adoc
index de0f187..1b2d6e6 100644
--- a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/bootstrapping.adoc
+++ b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/bootstrapping.adoc
@@ -8,7 +8,7 @@ Integration tests instantiate an Apache Isis "runtime" (as a singleton) within a
 Because (depending on the size of your app) it takes a little time to bootstrap Apache Isis, the framework caches the runtime on a thread-local from one test to the next.
 
 
-The recommended way to bootstrapping of integration tests is done using a xref:rg:cms:classes/AppManifest2-bootstrapping.adoc[`Module`] implementation, along with the `IntegrationTestAbstract3` superclass.
+The recommended way to bootstrapping of integration tests is done using a xref:applib:cms:classes/AppManifest2-bootstrapping.adoc[`Module`] implementation, along with the `IntegrationTestAbstract3` superclass.
 
 For example, the xref:simpleapp:ROOT:about.adoc[SimpleApp archetype]'s integration tests all inherit from this class:
 
diff --git a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/configuration-properties.adoc b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/configuration-properties.adoc
index 100070a..f826893 100644
--- a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/configuration-properties.adoc
+++ b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/configuration-properties.adoc
@@ -5,7 +5,7 @@ include::_attributes.adoc[]
 
 
 The recommended way to run integration tests is against an HSQLDB in-memory database.
-This can be done using the application's usual xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`], and then overriding JDBC URL and similar.
+This can be done using the application's usual xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`], and then overriding JDBC URL and similar.
 
 If inheriting from `IntegrationTestAbstract3`'s then these configuration properties are set up automatically:
 
diff --git a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/typical-usage.adoc b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/typical-usage.adoc
index 105ec31..273634e 100644
--- a/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/typical-usage.adoc
+++ b/core/testsupport/integtestsupport/_adoc/modules/ROOT/pages/integ-test-support/typical-usage.adoc
@@ -57,7 +57,7 @@ public class ToDoItemIntegTest extends AbstractToDoIntegTest {
     ...
 }
 ----
-<1> the xref:rg:cms:classes/super.adoc#FixtureScripts[`FixtureScripts`] domain service is injected, providing us with the ability to run fixture scripts
+<1> the xref:applib:cms:classes/super.adoc#FixtureScripts[`FixtureScripts`] domain service is injected, providing us with the ability to run fixture scripts
 <2> likewise, an instance of the `ToDoItems` domain service is injected.  We'll use this to lookup...
 <3> the object under test, held as a field
 <4> the fixture script for this test; it deletes all existing todo items (for the current user only) and then recreates them
diff --git a/core/testsupport/integtestsupport/_adoc/modules/mvn/pages/intro.adoc b/core/testsupport/integtestsupport/_adoc/modules/mvn/pages/intro.adoc
index 69d4816..5c9e280 100644
--- a/core/testsupport/integtestsupport/_adoc/modules/mvn/pages/intro.adoc
+++ b/core/testsupport/integtestsupport/_adoc/modules/mvn/pages/intro.adoc
@@ -24,14 +24,14 @@ The `validate` goal is by default bound to the `test` phase, and the `swagger` g
 The `xsd` goal meanwhile defaults to the `generate-resources` phase, and this is generally used in a completely separate sub-module.
 An example can be found in the (non-ASF) http://github.com/isisaddons/isis-app-todoapp[Isis addons' todoapp] example app; the separate submodule that uses the `xsd` goal is (also) called `todoapp-xsd`.
 
-All of these goals require an xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] to point the plugin at, so that it knows how to bootstrap an Isis runtime.
+All of these goals require an xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] to point the plugin at, so that it knows how to bootstrap an Isis runtime.
 This is discussed below, followed by sections on configuring the two goals.
 
 
 
 == `AppManifest`
 
-As noted in the introduction, all the goals require an xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] to point the plugin at, so that it knows how to bootstrap an Isis runtime.
+As noted in the introduction, all the goals require an xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] to point the plugin at, so that it knows how to bootstrap an Isis runtime.
 
 This can be extremely minimal; it isn't necessary to use the main `AppManifest` (in the `app` module) used to bootstrap the application, you can instead use a cut-down one.
 This then allows the plugins to be run during the build of the `dom` module, rather than having to run in the context of the `integtest` module.
diff --git a/core/testsupport/unittestsupport/_adoc/modules/ROOT/pages/unit-test-support/contract-tests.adoc b/core/testsupport/unittestsupport/_adoc/modules/ROOT/pages/unit-test-support/contract-tests.adoc
index 80bee3f..87a31c2 100644
--- a/core/testsupport/unittestsupport/_adoc/modules/ROOT/pages/unit-test-support/contract-tests.adoc
+++ b/core/testsupport/unittestsupport/_adoc/modules/ROOT/pages/unit-test-support/contract-tests.adoc
@@ -40,7 +40,7 @@ If using DataNucleus against an RDBMS (as you probably are) then we strongly rec
 
 * second, `SortedSet` is preferable to `Set` because then the order is well-defined and predictable (to an end user, to the programmer). +
 +
-The xref:rg:cms:classes/utility.adoc#ObjectContracts[`ObjectContracts`]  utility class substantially simplifies the task of implementing `Comparable` in your domain classes.
+The xref:applib:cms:classes/utility.adoc#ObjectContracts[`ObjectContracts`]  utility class substantially simplifies the task of implementing `Comparable` in your domain classes.
 
 * third, if the relationship is bidirectional then JDO/Objectstore will automatically maintain the relationship.
 
diff --git a/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/hints-and-tips/restful-image-property.adoc b/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/hints-and-tips/restful-image-property.adoc
index 63206e4..8db88d4 100644
--- a/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/hints-and-tips/restful-image-property.adoc
+++ b/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/hints-and-tips/restful-image-property.adoc
@@ -18,6 +18,6 @@ This is in the form:
 
     (filename):(mime type):(binary data in base64)
 
-This is basically the xref:rg:cms:classes/value-types.adoc#Blob[`Blob`] value type, in string form.
+This is basically the xref:applib:cms:classes/value-types.adoc#Blob[`Blob`] value type, in string form.
 
 To use, split the parts then format the mime type and base64 data correctly before using as source in an `<img>` tag.
diff --git a/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/layout-resources.adoc b/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/layout-resources.adoc
index 36527a6..f6a283f 100644
--- a/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/layout-resources.adoc
+++ b/core/viewer-restfulobjects/_adoc/modules/ROOT/pages/layout-resources.adoc
@@ -127,7 +127,7 @@ The representation returned by the domain object resource (section 14.4 of the R
 }
 ----
 
-Note that because of dynamic icons (the xref:rg:cms:methods.adoc#iconName[`iconName()`] supporting method) the image returned can vary on an instance-by-instance basis.
+Note that because of dynamic icons (the xref:applib:cms:methods.adoc#iconName[`iconName()`] supporting method) the image returned can vary on an instance-by-instance basis.
 
 
 == Domain Object Layout
diff --git a/core/viewer-wicket/_adoc/modules/ROOT/pages/features/blob-attachments.adoc b/core/viewer-wicket/_adoc/modules/ROOT/pages/features/blob-attachments.adoc
index cce0a9f..c9923da 100644
--- a/core/viewer-wicket/_adoc/modules/ROOT/pages/features/blob-attachments.adoc
+++ b/core/viewer-wicket/_adoc/modules/ROOT/pages/features/blob-attachments.adoc
@@ -4,7 +4,7 @@ include::_attributes.adoc[]
 
 
 
-The Apache Isis application library provides the xref:rg:cms:classes/value-types.adoc#Blob[Blob] value type (binary large objects) and also the xref:rg:cms:classes/value-types.adoc#Clob[Clob]
+The Apache Isis application library provides the xref:applib:cms:classes/value-types.adoc#Blob[Blob] value type (binary large objects) and also the xref:applib:cms:classes/value-types.adoc#Clob[Clob]
 value type (character large object), each of which also includes metadata about the data (specifically the filename and mime type).
 
 A class can define a property using either of these types, for example:
diff --git a/core/viewer-wicket/_adoc/modules/ROOT/pages/layout/file-based.adoc b/core/viewer-wicket/_adoc/modules/ROOT/pages/layout/file-based.adoc
index 441427d..66d6a51 100644
--- a/core/viewer-wicket/_adoc/modules/ROOT/pages/layout/file-based.adoc
+++ b/core/viewer-wicket/_adoc/modules/ROOT/pages/layout/file-based.adoc
@@ -14,7 +14,7 @@ File-based layouts offer a number of benefits:
 
 * UI hints can be provided for contributed xref:ug:fun:programming-model.adoc#contributed-action[actions] that are synthesised at runtime.
 
-It is also possible to download an initial `.layout.xml` - capturing any existing layout metadata - using the xref:applib:svc:metadata-api/LayoutService.adoc[`LayoutService`] (exposed on the prototyping menu) or using a xref:rg:cms:classes/mixins.adoc#Object[mixin action] contributed to every domain object.
+It is also possible to download an initial `.layout.xml` - capturing any existing layout metadata - using the xref:applib:svc:metadata-api/LayoutService.adoc[`LayoutService`] (exposed on the prototyping menu) or using a xref:applib:cms:classes/mixins.adoc#Object[mixin action] contributed to every domain object.
 
 There are some downsides, though:
 
@@ -25,7 +25,7 @@ There are some downsides, though:
 * there is no notion of inheritance, so a `.layout.xml` is required for all concrete classes and also for any abstract classes (if used as a collection type).
 In contrast, the dewey-decimal format `@MemberOrder` annotation allows the metadata of the subclass its superclasses to fit together relatively seamlessly.
 
-The `Xxx.layout.xml` file is just the serialized form of a xref:rg:cms:classes/layout.adoc[`Grid`] layout class defined within Apache Isis' applib.
+The `Xxx.layout.xml` file is just the serialized form of a xref:applib:cms:classes/layout.adoc[`Grid`] layout class defined within Apache Isis' applib.
 These are JAXB-annotated classes with corresponding XSD schemas; the upshot of that is that IDEs such as IntelliJ and Eclipse can provide "intellisense", making iteasy to author such layout files.
 
 
@@ -35,7 +35,7 @@ A domain object may also have multiple layouts.
 For example, there may be the capability to switch into an "edit" mode, which perhaps hides some class members, shows others (perhaps mixins specific to data entry).
 Another reason might be to support different tenancies/user groups, where different business processes might require a slightly different UI representation.
 
-One way in which the domain object can specify an alternate layout is through its xref:rg:cms:methods.adoc#layout[`layout()`] method.
+One way in which the domain object can specify an alternate layout is through its xref:applib:cms:methods.adoc#layout[`layout()`] method.
 If this returns a non-null value, say "edit", then this is used to locate an alternative layout, in the form `Xxx-edit.layout.xml`.
 
 
@@ -63,7 +63,7 @@ The rows and columns are closely modelled on link:http://getbootstrap.com[Bootst
 
 * those that defines common components, of: fieldsets (previously called member groups or property groups), properties, collections, actions and also the title/icon of the domain object itself.
 
-More information about these classes can be found in xref:rg:cms:classes/layout.adoc[the reference guide].  More information on Bootstrap 3's grid system can be found link:http://getbootstrap.com/css/#grid[here].
+More information about these classes can be found in xref:applib:cms:classes/layout.adoc[the reference guide].  More information on Bootstrap 3's grid system can be found link:http://getbootstrap.com/css/#grid[here].
 
 
 
@@ -362,7 +362,7 @@ from the top of the page slightly, using the following CSS:
 == Migrating from earlier versions
 
 As noted earlier on, it is possible to download layout XML files using the xref:applib:svc:metadata-api/LayoutService.adoc[`LayoutService`] (exposed on the prototyping menu); this will download a ZIP file of layout XML files for all domain entities and view models.
-Alternatively the layout XML for a single domain object can be downloaded using the xref:rg:cms:classes/mixins.adoc#Object[mixin action] (contributed to every domain object).
+Alternatively the layout XML for a single domain object can be downloaded using the xref:applib:cms:classes/mixins.adoc#Object[mixin action] (contributed to every domain object).
 
 There are four "styles":
 
@@ -424,11 +424,11 @@ Download either for a single domain object, or download all domain objects (enti
 
 For more information about layouts, see:
 
-* xref:applib:svc:metadata-api/LayoutService.adoc[`LayoutService`] (whose functionality is exposed on the prototyping menu as an action) and lso the a xref:rg:cms:classes/mixins.adoc#Object[mixin action]
+* xref:applib:svc:metadata-api/LayoutService.adoc[`LayoutService`] (whose functionality is exposed on the prototyping menu as an action) and lso the a xref:applib:cms:classes/mixins.adoc#Object[mixin action]
 
 * xref:applib:svc:presentation-layer-spi/GridService.adoc[`GridService`] and its supporting services, xref:applib:svc:presentation-layer-spi/GridLoaderService.adoc[`GridLoaderService`] and xref:applib:svc:presentation-layer-spi/GridSystemService.adoc[`GridSystemService`]
 
-* xref:rg:cms:classes/layout.adoc[grid layout classes], defined in the Apache Isis applib
+* xref:applib:cms:classes/layout.adoc[grid layout classes], defined in the Apache Isis applib
 
 
 
diff --git a/core/viewer-wicket/_adoc/modules/ROOT/pages/menubars-layout/file-based.adoc b/core/viewer-wicket/_adoc/modules/ROOT/pages/menubars-layout/file-based.adoc
index 825a93c..b7c8961 100644
--- a/core/viewer-wicket/_adoc/modules/ROOT/pages/menubars-layout/file-based.adoc
+++ b/core/viewer-wicket/_adoc/modules/ROOT/pages/menubars-layout/file-based.adoc
@@ -18,7 +18,7 @@ There are some disadvantages to using file-based layouts:
 
 * they also suffer from syntactic fragility: an invalid XML document will result in no metadata for the entire class.
 
-The `menubars.layout.xml` file is just the serialized form of a xref:rg:cms:classes/layout.adoc[`MenuBars`] layout class defined within Apache Isis' applib.
+The `menubars.layout.xml` file is just the serialized form of a xref:applib:cms:classes/layout.adoc[`MenuBars`] layout class defined within Apache Isis' applib.
 These are JAXB-annotated classes with corresponding XSD schemas; the upshot of that
 is that IDEs such as IntelliJ and Eclipse can provide "intellisense", making it easy to author such layout files.
 
diff --git a/examples/apps/simpleapp/_adoc/modules/ROOT/pages/about.adoc b/examples/apps/simpleapp/_adoc/modules/ROOT/pages/about.adoc
index 9bc8463..d3926f8 100644
--- a/examples/apps/simpleapp/_adoc/modules/ROOT/pages/about.adoc
+++ b/examples/apps/simpleapp/_adoc/modules/ROOT/pages/about.adoc
@@ -676,7 +676,7 @@ If you are running the app from an IDE, then you can specify the fixture script
 
 image::simpleapp-webapp-with-fixtures.png[width="600px",link="{imagesdir}/simpleapp-webapp-with-fixtures.png"]
 
-Alternatively, you can run with a different xref:rg:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] using the `--appManifest` (or `-m`) flag.
+Alternatively, you can run with a different xref:applib:cms:classes/AppManifest-bootstrapping.adoc[`AppManifest`] using the `--appManifest` (or `-m`) flag.
 The archetype provides
 `domainapp.app.DomainAppAppManifestWithFixtures` which specifies the aforementioned `RecreateSimpleObjects` fixture.