code module include:: fixes

Author: RichardSmedley

modules/concept-docs/pages/compression.adoc

@@ -80,7 +80,7 @@ To safeguard against the case of several thousand documents stealing CPU time to
 
 [source,java]
 ----
-include::example$CompressionExample.java[tag=compression_1,indent=0]
+include::devguide:example$java/CompressionExample.java[tag=compression_1,indent=0]
 ----
 
 

modules/concept-docs/pages/transactions-cleanup.adoc

@@ -18,7 +18,7 @@ The cleanup settings can be configured as so:
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=config-cleanup,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=config-cleanup,indent=0]
 ----
 
 The settings supported by `TransactionsCleanupConfig` are:
@@ -38,7 +38,7 @@ If an application needs to monitor cleanup, it may subscribe to these events:
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=cleanup-events,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=cleanup-events,indent=0]
 ----
 
 `TransactionCleanupEndRunEvent` is raised whenever a current 'run' is finished, and contains statistics from the run.

modules/concept-docs/pages/transactions-error-handling.adoc

@@ -19,14 +19,14 @@ include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tag=txnfaile
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=config-expiration,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=config-expiration,indent=0]
 ----
 
 Alternatively it can be configured at the per-transaction level:
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=config-expiration-per,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=config-expiration-per,indent=0]
 ----
 
 include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tag=txnfailed1]
@@ -37,5 +37,5 @@ Pulling all of the above together, this is the suggested best practice for error
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=full-error-handling,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=full-error-handling,indent=0]
 ----

modules/concept-docs/pages/transactions.adoc

@@ -19,7 +19,7 @@ include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tags=intro]
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=create-simple,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=create-simple,indent=0]
 ----
 
 include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tags=mechanics;!library-cleanup-process]
@@ -39,7 +39,7 @@ The application can use this to signal why it triggered a rollback, as so:
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=rollback-cause,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=rollback-cause,indent=0]
 ----
 
 After a transaction is rolled back, it cannot be committed, no further operations are allowed on it, and the SDK will not try to automatically commit it at the end of the code block.
@@ -58,14 +58,14 @@ include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tag=custom-m
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=custom-metadata,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=custom-metadata,indent=0]
 ----
 
 or at an individual transaction level with:
 
 [source,java]
 ----
-include::howtos:example$TransactionsExample.java[tag=custom-metadata-per,indent=0]
+include::devguide:example$java/TransactionsExample.java[tag=custom-metadata-per,indent=0]
 ----
 
 include::{version-common}@sdk:shared:partial$acid-transactions.adoc[tag=integrated-sdk-custom-metadata-2,indent=0]

modules/howtos/pages/analytics-using-sdk.adoc

@@ -34,14 +34,14 @@ Before starting, here's all imports used in the following examples:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=imports,indent=0]
+include::devguide:example$java/Analytics.java[tag=imports,indent=0]
 ----
 
 Here's a complete example of doing an analytics query and handling the results:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=simple,indent=0]
+include::devguide:example$java/Analytics.java[tag=simple,indent=0]
 ----
 
 Let's break it down. An analytics query is always performed at the `Cluster` level, using the `analyticsQuery` method. It takes the statement as a required argument and then allows to provide additional options if needed (in the example above, no options are specified).
@@ -66,14 +66,14 @@ The first example shows how to provide them by name:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=named,indent=0]
+include::devguide:example$java/Analytics.java[tag=named,indent=0]
 ----
 
 The second example by position:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=positional,indent=0]
+include::devguide:example$java/Analytics.java[tag=positional,indent=0]
 ----
 
 What style you choose is up to you, for readability in more complex queries we generally recommend using the named parameters.
@@ -88,7 +88,7 @@ Rows can be consumed either through a `JsonObject` directly, turned into a java
 
 [source,java]
 ----
-include::example$Analytics.java[tag=rowsasobject,indent=0]
+include::devguide:example$java/Analytics.java[tag=rowsasobject,indent=0]
 ----
 
 
@@ -110,7 +110,7 @@ For example, here is how you can print the `executionTime` of a query:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=printmetrics,indent=0]
+include::devguide:example$java/Analytics.java[tag=printmetrics,indent=0]
 ----
 
 == Analytics Options
@@ -136,7 +136,7 @@ By default, the analytics engine will return whatever is currently in the index
 
 [source,java]
 ----
-include::example$Analytics.java[tag=scanconsistency,indent=0]
+include::devguide:example$java/Analytics.java[tag=scanconsistency,indent=0]
 ----
 
 
@@ -146,7 +146,7 @@ The SDK will always send a client context ID with each query, even if none is pr
 
 [source,java]
 ----
-include::example$Analytics.java[tag=clientcontextid,indent=0]
+include::devguide:example$java/Analytics.java[tag=clientcontextid,indent=0]
 ----
 
 
@@ -156,7 +156,7 @@ By default, every analytics query has the same priority on the server. By settin
 
 [source,java]
 ----
-include::example$Analytics.java[tag=priority,indent=0]
+include::devguide:example$java/Analytics.java[tag=priority,indent=0]
 ----
 
 
@@ -166,7 +166,7 @@ If the query is marked as readonly, both the server and the SDK can improve proc
 
 [source,java]
 ----
-include::example$Analytics.java[tag=readonly,indent=0]
+include::devguide:example$java/Analytics.java[tag=readonly,indent=0]
 ----
 
 === Custom JSON Serializer
@@ -192,14 +192,14 @@ A simple reactive query is similar to the blocking one:
 
 [source,java]
 ----
-include::example$Analytics.java[tag=simplereactive,indent=0]
+include::devguide:example$java/Analytics.java[tag=simplereactive,indent=0]
 ----
 
 This query will stream all rows as they become available from the server. If you want to manually control the data flow (which is important if you are streaming a lot of rows which could cause a potential out of memory situation) you can do this by using explicit `request()` calls.
 
 [source,java]
 ----
-include::example$Analytics.java[tag=backpressure,indent=0]
+include::devguide:example$java/Analytics.java[tag=backpressure,indent=0]
 ----
 
 In this example we initially request a batch size of 10 rows (so streaming can begin).

modules/howtos/pages/collecting-information-and-logging.adoc

@@ -186,7 +186,7 @@ If you want to set it to DEBUG (or the JUL equivalent: Fine) you can do it like
 
 [source,java]
 ----
-include::example$CollectingInformationAndLogging.java[tag=collecting_information_and_logging_1,indent=0]
+include::devguide:example$java/CollectingInformationAndLogging.java[tag=collecting_information_and_logging_1,indent=0]
 ----
 
 TIP: We do not recommend using JUL in production.
@@ -215,7 +215,7 @@ The following code subscribes to the event bus and prints out all events that ar
 
 [source,java]
 ----
-include::example$CollectingInformationAndLogging.java[tag=collecting_information_and_logging_3,indent=0]
+include::devguide:example$java/CollectingInformationAndLogging.java[tag=collecting_information_and_logging_3,indent=0]
 ----
 
 This leads to output similar to this:
@@ -246,7 +246,7 @@ If you want to redact client logs (for example before handing them off to the Co
 
 [source,java]
 ----
-include::example$CollectingInformationAndLogging.java[tag=collecting_information_and_logging_4,indent=0]
+include::devguide:example$java/CollectingInformationAndLogging.java[tag=collecting_information_and_logging_4,indent=0]
 ----
 
 Different redaction levels are supported -- please see the `RedactionLevel` enum description for more information.

modules/howtos/pages/concurrent-async-apis.adoc

@@ -13,7 +13,7 @@ Each blocking API provides access to its reactive counterpart through the `react
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=access]
+include::devguide:example$java/AsyncOperations.java[tag=access]
 ----
 
 The reactive API uses the https://projectreactor.io/[Project Reactor] library as the underlying implementation, so it exposes its `Mono` and `Flux` types accordingly. As a rule of thumb, if the blocking API returns a type `T` the reactive counterpart returns `Mono<T>` if one (or no) results is expected or in some cases `Flux<T>` if there are more than one expected. We *highly* recommend that you make yourself familar with the https://projectreactor.io/docs/core/release/reference/[reactor documentation] to understand its fundamentals and also unlock its full potential.
@@ -22,14 +22,14 @@ The following example fetches a document and prints out the `GetResult` once it
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=simple-get]
+include::devguide:example$java/AsyncOperations.java[tag=simple-get]
 ----
 
 It is important to understand that reactive types are lazy, which means that they are only executed when a consumer subscribes to them. So a code like this won't even be executed at all:
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=non-used-upsert]
+include::devguide:example$java/AsyncOperations.java[tag=non-used-upsert]
 ----
 
 Modern IDEs like IntelliJ even warn you about that:
@@ -40,7 +40,7 @@ You will come across the `Flux` type in APIs like query where there is one or mo
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=verbose-query]
+include::devguide:example$java/AsyncOperations.java[tag=verbose-query]
 ----
 
 The `QueryResult` itself is wrapped in a `Mono`, but the class itself carries a `Flux<T>` of rows where `T` is a type of choice you can convert it to (in this example we simply convert it into `JsonObject`). The `flatMap` operator allows to map the stream or rows into the previous stream of the original result. If you have more question on how this works, check out the documentation https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html#flatMap-java.util.function.Function-[here].
@@ -52,7 +52,7 @@ You can access this API by using the `async()` accessor methods both on the bloc
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=access-async]
+include::devguide:example$java/AsyncOperations.java[tag=access-async]
 ----
 
 We recommend using this API only if you are either writing integration code for higher level concurrency mechanisms or you really need the last drop of performance. In all other cases, the blocking API (for simplicity) or the reactive API (for richness in operators) is likely the better choice.
@@ -64,7 +64,7 @@ While it can be done with the async API as well, we recommend using the reactive
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=simple-bulk]
+include::devguide:example$java/AsyncOperations.java[tag=simple-bulk]
 ----
 
 This code grabs a list of keys to fetch and passes them to `ReactiveCollection#get(String)`. Since this is happening asynchronously, the results will return in whatever order they come back from the server cluster. The `block()` at the end waits until all results have been collected. Of course the blocking part at the end is optional, but it shows that you can mix and match reactive and blocking code to on the one hand benefit from simplicity, but always go one layer below for the more powerful concepts if needed.
@@ -75,7 +75,7 @@ Here is how you can ignore individual errors:
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=ignore-bulk]
+include::devguide:example$java/AsyncOperations.java[tag=ignore-bulk]
 ----
 
 The `.onErrorResume(e -> Mono.empty()))` returns an empty `Mono` regardless of the error. Since you have the exception in scope, you can also decide based on the actual error if you want to ignore it or propagate/fallback to a different reactive computation.
@@ -84,7 +84,7 @@ If you want to separate out failures from completions, one way would be to use s
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=split-bulk]
+include::devguide:example$java/AsyncOperations.java[tag=split-bulk]
 ----
 
 If the result succeeds the side-effect method `doOnNext` is used to store it into the `successfulResults` and if the operation fails we are utilizing the same operator as before (`onErrorResume`) to store it in the `erroredResults` map -- but then also to ignore it for the overall sequence.
@@ -93,7 +93,7 @@ Finally, it is also possible to retry individual failures before giving up. The
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=retry-bulk]
+include::devguide:example$java/AsyncOperations.java[tag=retry-bulk]
 ----
 
 It is recommended to check out the `retry` and `retryBackoff` methods for their configuration options and overloads. Of course, all the operators shown here can be combined to achieve exactly the semantics you need. Finally, for even advanced retry policies you can utilize the retry functionality in the https://projectreactor.io/docs/extra/release/api/reactor/retry/Retry.html[reactor-extra] package.
@@ -122,7 +122,7 @@ Then, you can use the various conversion methods to convert back and forth betwe
 
 [source,java]
 ----
-include::example$AsyncOperations.java[tag=rs-conversion]
+include::devguide:example$java/AsyncOperations.java[tag=rs-conversion]
 ----
 
 The same strategy can be used to convert to https://akka.io/[Akka], but if you are working in the scala world we recommend using our first-class Scala SDK directly instead!

modules/howtos/pages/concurrent-document-mutations.adoc

@@ -14,7 +14,7 @@ include::{version-common}@sdk:shared:partial$cas.adoc[tag=errors]
 
 [source,java]
 ----
-include::example$Cas.java[tag=handlingerrors,indent=0]
+include::devguide:example$java/Cas.java[tag=handlingerrors,indent=0]
 ----
 
 Sometimes more logic is needed when performing updates, for example, if a property is mutually exclusive with another property; only one or the other can exist, but not both.
@@ -28,7 +28,7 @@ include::{version-common}@sdk:shared:partial$cas.adoc[tag=locking]
 
 [source,java]
 ----
-include::example$Cas.java[tag=locking,indent=0]
+include::devguide:example$java/Cas.java[tag=locking,indent=0]
 ----
 
 The handler will unlock the item either via an explicit unlock operation ([.api]`unlock`) or implicitly via modifying the item with the correct CAS.