Migrate to Asciidoctor Tabs

Author: rwinch

antora-playbook.yml

@@ -4,8 +4,6 @@
 antora:
   extensions:
     - '@antora/collector-extension'
-    - require: '@springio/antora-extensions/tabs-migration-extension'
-      unwrap_example_block: always
     - require: '@springio/antora-extensions/root-component-extension'
       root_component_name: 'data-commons'
 site:
@@ -35,5 +33,5 @@ runtime:
     format: pretty
 ui:
   bundle:
-    url: https://github.com/spring-io/antora-ui-spring/releases/download/latest/ui-bundle.zip
+    url: https://github.com/spring-io/antora-ui-spring/releases/download/v0.3.0/ui-bundle.zip
     snapshot: true

modules/ROOT/pages/auditing.adoc

@@ -17,7 +17,6 @@ Applications that only track creation and modification dates are not required do
 We provide `@CreatedBy` and `@LastModifiedBy` to capture the user who created or modified the entity as well as `@CreatedDate` and `@LastModifiedDate` to capture when the change happened.
 
 .An audited entity
-====
 [source,java]
 ----
 class Customer {
@@ -31,15 +30,13 @@ class Customer {
   // … further properties omitted
 }
 ----
-====
 
 As you can see, the annotations can be applied selectively, depending on which information you want to capture.
 The annotations, indicating to capture when changes are made, can be used on properties of type JDK8 date and time types, `long`, `Long`, and legacy Java `Date` and `Calendar`.
 
 Auditing metadata does not necessarily need to live in the root level entity but can be added to an embedded one (depending on the actual store in use), as shown in the snippet below.
 
 .Audit metadata in embedded entity
-====
 [source,java]
 ----
 class Customer {
@@ -59,7 +56,6 @@ class AuditMetadata {
 
 }
 ----
-====
 
 [[auditing.interfaces]]
 === Interface-based Auditing Metadata
@@ -73,7 +69,6 @@ In case you use either `@CreatedBy` or `@LastModifiedBy`, the auditing infrastru
 The following example shows an implementation of the interface that uses Spring Security's `Authentication` object:
 
 .Implementation of `AuditorAware` based on Spring Security
-====
 [source, java]
 ----
 class SpringSecurityAuditorAware implements AuditorAware<User> {
@@ -89,7 +84,6 @@ class SpringSecurityAuditorAware implements AuditorAware<User> {
   }
 }
 ----
-====
 
 The implementation accesses the `Authentication` object provided by Spring Security and looks up the custom `UserDetails` instance that you have created in your `UserDetailsService` implementation. We assume here that you are exposing the domain user through the `UserDetails` implementation but that, based on the `Authentication` found, you could also look it up from anywhere.
 
@@ -102,7 +96,6 @@ We provide an `ReactiveAuditorAware<T>` SPI interface that you have to implement
 The following example shows an implementation of the interface that uses reactive Spring Security's `Authentication` object:
 
 .Implementation of `ReactiveAuditorAware` based on Spring Security
-====
 [source, java]
 ----
 class SpringSecurityAuditorAware implements ReactiveAuditorAware<User> {
@@ -118,6 +111,5 @@ class SpringSecurityAuditorAware implements ReactiveAuditorAware<User> {
   }
 }
 ----
-====
 
 The implementation accesses the `Authentication` object provided by Spring Security and looks up the custom `UserDetails` instance that you have created in your `UserDetailsService` implementation. We assume here that you are exposing the domain user through the `UserDetails` implementation but that, based on the `Authentication` found, you could also look it up from anywhere.

modules/ROOT/pages/dependencies.adoc

@@ -4,7 +4,6 @@
 Due to the different inception dates of individual Spring Data modules, most of them carry different major and minor version numbers. The easiest way to find compatible ones is to rely on the Spring Data Release Train BOM that we ship with the compatible versions defined. In a Maven project, you would declare this dependency in the `<dependencyManagement />` section of your POM as follows:
 
 .Using the Spring Data release train BOM
-====
 [source, xml, subs="+attributes"]
 ----
 <dependencyManagement>
@@ -19,7 +18,6 @@ Due to the different inception dates of individual Spring Data modules, most of
   </dependencies>
 </dependencyManagement>
 ----
-====
 
 [[dependencies.train-names]]
 [[dependencies.train-version]]
@@ -33,7 +31,6 @@ The version name follows `+${calver}+` for GA releases and service releases and
 You can find a working example of using the BOMs in our https://github.com/spring-projects/spring-data-examples/tree/main/bom[Spring Data examples repository]. With that in place, you can declare the Spring Data modules you would like to use without a version in the `<dependencies />` block, as follows:
 
 .Declaring a dependency to a Spring Data module
-====
 [source, xml]
 ----
 <dependencies>
@@ -43,7 +40,6 @@ You can find a working example of using the BOMs in our https://github.com/sprin
   </dependency>
 <dependencies>
 ----
-====
 
 [[dependencies.spring-boot]]
 == Dependency Management with Spring Boot

modules/ROOT/pages/entity-callbacks.adoc

@@ -24,7 +24,6 @@ An `EntityCallback` is directly associated with its domain type through its gene
 Each Spring Data module typically ships with a set of predefined `EntityCallback` interfaces covering the entity lifecycle.
 
 .Anatomy of an `EntityCallback`
-====
 [source,java]
 ----
 @FunctionalInterface
@@ -44,10 +43,8 @@ public interface BeforeSaveCallback<T> extends EntityCallback<T> {
 <1> `BeforeSaveCallback` specific method to be called before an entity is saved. Returns a potentially modifed instance.
 <2> The entity right before persisting.
 <3> A number of store specific arguments like the _collection_ the entity is persisted to.
-====
 
 .Anatomy of a reactive `EntityCallback`
-====
 [source,java]
 ----
 @FunctionalInterface
@@ -67,14 +64,12 @@ public interface ReactiveBeforeSaveCallback<T> extends EntityCallback<T> {
 <1> `BeforeSaveCallback` specific method to be called on subscription, before an entity is saved. Emits a potentially modifed instance.
 <2> The entity right before persisting.
 <3> A number of store specific arguments like the _collection_ the entity is persisted to.
-====
 
 NOTE: Optional entity callback parameters are defined by the implementing Spring Data module and inferred from call site of `EntityCallback.callback()`.
 
 Implement the interface suiting your application needs like shown in the example below:
 
 .Example `BeforeSaveCallback`
-====
 [source,java]
 ----
 class DefaultingEntityCallback implements BeforeSaveCallback<Person>, Ordered {      <2>
@@ -97,7 +92,6 @@ class DefaultingEntityCallback implements BeforeSaveCallback<Person>, Ordered {
 ----
 <1> Callback implementation according to your requirements.
 <2> Potentially order the entity callback if multiple ones for the same domain type exist. Ordering follows lowest precedence.
-====
 
 [[entity-callbacks.register]]
 == Registering Entity Callbacks
@@ -108,7 +102,6 @@ Most template APIs already implement `ApplicationContextAware` and therefore hav
 The following example explains a collection of valid entity callback registrations:
 
 .Example `EntityCallback` Bean registration
-====
 [source,java]
 ----
 @Order(1)                                                           <1>
@@ -164,4 +157,3 @@ class UserCallbacks implements BeforeConvertCallback<User>,
 <2> `BeforeSaveCallback` receiving its order via the `Ordered` interface implementation.
 <3> `BeforeSaveCallback` using a lambda expression. Unordered by default and invoked last. Note that callbacks implemented by a lambda expression do not expose typing information hence invoking these with a non-assignable entity affects the callback throughput. Use a `class` or `enum` to enable type filtering for the callback bean.
 <4> Combine multiple entity callback interfaces in a single implementation class.
-====

modules/ROOT/pages/kotlin-coroutines.adoc

@@ -14,7 +14,6 @@ Spring Data modules provide support for Coroutines on the following scope:
 Coroutines support is enabled when `kotlinx-coroutines-core`, `kotlinx-coroutines-reactive` and `kotlinx-coroutines-reactor` dependencies are in the classpath:
 
 .Dependencies to add in Maven pom.xml
-====
 [source,xml]
 ----
 <dependency>
@@ -32,7 +31,6 @@ Coroutines support is enabled when `kotlinx-coroutines-core`, `kotlinx-coroutine
 	<artifactId>kotlinx-coroutines-reactor</artifactId>
 </dependency>
 ----
-====
 
 NOTE: Supported versions `1.3.0` and above.
 
@@ -62,7 +60,6 @@ Read this blog post about https://spring.io/blog/2019/04/12/going-reactive-with-
 
 Here is an example of a Coroutines repository:
 
-====
 [source,kotlin]
 ----
 interface CoroutineRepository : CoroutineCrudRepository<User, String> {
@@ -74,7 +71,6 @@ interface CoroutineRepository : CoroutineCrudRepository<User, String> {
     suspend fun findAllByFirstname(id: String): List<User>
 }
 ----
-====
 
 Coroutines repositories are built on reactive repositories to expose the non-blocking nature of data access through Kotlin's Coroutines.
 Methods on a Coroutines repository can be backed either by a query method or a custom implementation.

modules/ROOT/pages/object-mapping.adoc

@@ -113,7 +113,6 @@ class Person {
 ----
 
 .A generated Property Accessor
-====
 [source, java]
 ----
 class PersonPropertyAccessor implements PersistentPropertyAccessor {
@@ -140,7 +139,6 @@ class PersonPropertyAccessor implements PersistentPropertyAccessor {
 <2> By default, Spring Data uses field-access to read and write property values. As per visibility rules of `private` fields, `MethodHandles` are used to interact with fields.
 <3> The class exposes a `withId(…)` method that's used to set the identifier, e.g. when an instance is inserted into the datastore and an identifier has been generated. Calling `withId(…)` creates a new `Person` object. All subsequent mutations will take place in the new instance leaving the previous untouched.
 <4> Using property-access allows direct method invocations without using `MethodHandles`.
-====
 
 This gives us a roundabout 25% performance boost over reflection.
 For the domain class to be eligible for such optimization, it needs to adhere to a set of constraints:
@@ -156,7 +154,6 @@ By default, Spring Data attempts to use generated property accessors and falls b
 Let's have a look at the following entity:
 
 .A sample entity
-====
 [source, java]
 ----
 class Person {
@@ -193,7 +190,6 @@ class Person {
   }
 }
 ----
-====
 <1> The identifier property is final but set to `null` in the constructor.
 The class exposes a `withId(…)` method that's used to set the identifier, e.g. when an instance is inserted into the datastore and an identifier has been generated.
 The original `Person` instance stays unchanged as a new one is created.
@@ -230,7 +226,6 @@ It's an established pattern to rather use static factory methods to expose these
 Java's allows a flexible design of domain classes where a subclass could define a property that is already declared with the same name in its superclass.
 Consider the following example:
 
-====
 [source,java]
 ----
 public class SuperType {
@@ -272,7 +267,6 @@ public class SubType extends SuperType {
    }
 }
 ----
-====
 
 Both classes define a `field` using assignable types. `SubType` however shadows `SuperType.field`.
 Depending on the class design, using the constructor could be the only default approach to set `SuperType.field`.
@@ -315,16 +309,13 @@ Other constructors will be ignored.
 
 Consider the following `data` class `Person`:
 
-====
 [source,kotlin]
 ----
 data class Person(val id: String, val name: String)
 ----
-====
 
 The class above compiles to a typical class with an explicit constructor.We can customize this class by adding another constructor and annotate it with `@PersistenceCreator` to indicate a constructor preference:
 
-====
 [source,kotlin]
 ----
 data class Person(var id: String, val name: String) {
@@ -333,17 +324,14 @@ data class Person(var id: String, val name: String) {
     constructor(id: String) : this(id, "unknown")
 }
 ----
-====
 
 Kotlin supports parameter optionality by allowing default values to be used if a parameter is not provided.
 When Spring Data detects a constructor with parameter defaulting, then it leaves these parameters absent if the data store does not provide a value (or simply returns `null`) so Kotlin can apply parameter defaulting.Consider the following class that applies parameter defaulting for `name`
 
-====
 [source,kotlin]
 ----
 data class Person(var id: String, val name: String = "unknown")
 ----
-====
 
 Every time the `name` parameter is either not part of the result or its value is `null`, then the `name` defaults to `unknown`.
 
@@ -353,12 +341,10 @@ Every time the `name` parameter is either not part of the result or its value is
 In Kotlin, all classes are immutable by default and require explicit property declarations to define mutable properties.
 Consider the following `data` class `Person`:
 
-====
 [source,kotlin]
 ----
 data class Person(val id: String, val name: String)
 ----
-====
 
 This class is effectively immutable.
 It allows creating new instances as Kotlin generates a `copy(…)` method that creates new object instances copying all property values from the existing object and applying property values provided as arguments to the method.
@@ -368,7 +354,6 @@ It allows creating new instances as Kotlin generates a `copy(…)` method that c
 
 Kotlin allows declaring https://kotlinlang.org/docs/inheritance.html#overriding-properties[property overrides] to alter properties in subclasses.
 
-====
 [source,kotlin]
 ----
 open class SuperType(open var field: Int)
@@ -377,13 +362,11 @@ class SubType(override var field: Int = 1) :
 	SuperType(field) {
 }
 ----
-====
 
 Such an arrangement renders two properties with the name `field`.
 Kotlin generates property accessors (getters and setters) for each property in each class.
 Effectively, the code looks like as follows:
 
-====
 [source,java]
 ----
 public class SuperType {
@@ -421,7 +404,6 @@ public final class SubType extends SuperType {
    }
 }
 ----
-====
 
 Getters and setters on `SubType` set only `SubType.field` and not `SuperType.field`.
 In such an arrangement, using the constructor is the only default approach to set `SuperType.field`.
@@ -446,7 +428,6 @@ Spring Data can read and write types that define properties using Value Classes.
 
 Consider the following domain model:
 
-====
 [source,kotlin]
 ----
 @JvmInline
@@ -457,7 +438,6 @@ data class Contact(val id: String, val name:String, val emailAddress: EmailAddre
 
 <1> A simple value class with a non-nullable value type.
 <2> Data class defining a property using the `EmailAddress` value class.
-====
 
 NOTE: Non-nullable properties using non-primitive value types are flattened in the compiled class to the value type.
 Nullable primitive value types or nullable value-in-value types are represented with their wrapper type and that affects how value types are represented in the database.