refactor: Make individual adoc files correct

This sets the top level headings to 1 and fixes them in includes.

grooves-diagrams/src/main/kotlin/com/github/rahulsom/grooves/asciidoctor/EventsBlock.kt

@@ -12,7 +12,7 @@ import java.security.MessageDigest
  *
  * @author Rahul Somasunderam
  */
-class EventsBlock(name: String, config: Map<String, Any>) :
+class EventsBlock(name: String) :
     BlockProcessor(name, mapOf("contexts" to listOf(":literal"), "content_model" to ":simple")) {
 
     override fun process(parent: StructuralNode, reader: Reader, attributes: MutableMap<String, Any>?): Any {

grooves-docs/src/docs/asciidoc/diagramming.adoc

@@ -1,4 +1,4 @@
-== Creating your own diagrams
+= Creating your own diagrams
 
 In a gradle project, if you're using asciidoctor for documentation, you can generate diagrams using `grooves-diagrams`.
 

grooves-docs/src/docs/asciidoc/examples/aggregate.adoc

@@ -1,4 +1,4 @@
-=== Aggregates
+= Aggregates
 
 In our examples, to begin with, we will use one aggregate - a patient.
 We'll model our system such that there are events that get applied on a Patient's timeline.

grooves-docs/src/docs/asciidoc/examples/dependencies.adoc

@@ -1,4 +1,4 @@
-=== Dependencies
+= Dependencies
 
 The examples here use gradle to manage dependencies.
 You could very well be using Maven, or ant+ivy, or leiningen, or sbt.

grooves-docs/src/docs/asciidoc/examples/events.adoc

@@ -1,14 +1,14 @@
-=== Events
+= Events
 
 In our example, we're going to have a bunch of events that will modify the computed state of the `Patient`.
 
-==== Your Base Event
+== Your Base Event
 include::baseEvent.adoc[]
 
-==== Your business events
+== Your business events
 include::creationEvent.adoc[]
 
-==== Standard Grooves Events
+== Standard Grooves Events
 There are some Standard Grooves Events - JoinEvent, DisjoinEvent, DeprecatedBy, Deprecates, RevertEvent.
 Their implementation is similar to one another, but slightly different from your business events.
 

grooves-docs/src/docs/asciidoc/examples/frp.adoc

@@ -1,4 +1,4 @@
-=== FRP Style
+= FRP Style
 
 Sometimes, it is not ideal to create classes to implement the queries.
 Since 0.4.0, grooves has experimental support for doing this in a somewhat _Functional Reactive Programming_ style.

grooves-docs/src/docs/asciidoc/examples/joins.adoc

@@ -1,4 +1,4 @@
-=== Joins
+= Joins
 
 Joins are just snapshots of a different kind.
 With Grooves, they're always _One-To-Many_. _One-To-One_ is just a special case of _One-To-Many_.

grooves-docs/src/docs/asciidoc/examples/queries.adoc

@@ -1,4 +1,4 @@
-=== Queries
+= Queries
 
 [source,java,indent=0,role="primary"]
 .Java

grooves-docs/src/docs/asciidoc/examples/snapshot.adoc

@@ -1,4 +1,4 @@
-=== Snapshots
+= Snapshots
 
 Let's start with a snapshot that manages account balance for a patient.
 

grooves-docs/src/docs/asciidoc/hurdles.adoc

@@ -1,10 +1,10 @@
-== Hurdles
+= Hurdles
 
 While the theory is very simple, in practice, it's a little more complicated.
 The functions that you see above are very simple at first glance, but implementing an entire system based on it requires some patterns.
 That is the problem that Grooves aims to solve.
 
-=== Completeness of Queries
+== Completeness of Queries
 
 When applying events on a Snapshot, you need to be sure that you have handled every single event type.
 Let's say you've got 3 types of events for an aggregate and 2 snapshots.
@@ -14,7 +14,7 @@ Alas, Groovy and Java do not have case classes.
 
 There are some special kinds of Events that require a lot of complex handling:
 
-=== Reverting Events
+== Reverting Events
 
 Some times events are entered into an aggregate's timeline in error.
 This could be a system error, or a human error.
@@ -71,7 +71,7 @@ This should be interpreted as 6 cancels out 5, so 5 can no more cancel out 3.
   + 6 2016-01-16 .
 ....
 
-=== Merging Aggregates
+== Merging Aggregates
 
 `DeprecatedBy` and `Deprecates` is a pair of events that work together on aggregates of the same type.
 Sometimes, real world things merge together.
@@ -117,7 +117,7 @@ The exception to the rule is when we're reverting the merge.
 That might not always be true.
 Some systems might choose to continue adding events on an aggregate like 5.
 
-=== Reverting Merges
+== Reverting Merges
 
 Lets assume we got confused with a pair of aggregates like these and performed a merge like this.
 
@@ -154,7 +154,7 @@ This is complicated, but necessary in order to make the reads on both aggregates
   + 10 2016-01-12 reverted 6
 ....
 
-=== Performing joins
+== Performing joins
 
 In an event sourced system, even joins are just events.
 That way we can preserve their temporal changes.
@@ -172,7 +172,7 @@ That way we can preserve their temporal changes.
   + 5 2016-01-05 joins 1 converse 7
 ....
 
-=== Performing disjoins
+== Performing disjoins
 
 Since joins can change with time, you could have a situation where you need to perform a `disjoin`.
 In our example here, Mr Spock stops being the Science Officer when he becomes captain.

grooves-docs/src/docs/asciidoc/index.adoc

@@ -3,15 +3,16 @@
 :nofooter:
 :linkcss:
 :docinfo: shared
+:includedir: .
 
 Formerly, _Groovy + Event Sourcing_.
 Now, _Grooves_ is just a name.
 It supports Event Sourcing on many JVM languages.
 Examples and tests are included in java, kotlin, and of course, groovy.
 
-include::{includedir}/intro.adoc[]
+include::{includedir}/intro.adoc[leveloffset=1]
 
-include::{includedir}/hurdles.adoc[]
+include::{includedir}/hurdles.adoc[leveloffset=1]
 
 == How Grooves solves it
 
@@ -39,20 +40,20 @@ We will be using 4 different kinds of projects.
 * Kotlin - This is a SpringBoot Reactive Web project that uses RxMongo for persistence.
   This example uses Spring Reactor as the Reactive Streams Framework.
 
-include::{includedir}/examples/dependencies.adoc[]
+include::{includedir}/examples/dependencies.adoc[leveloffset=2]
 
-include::{includedir}/examples/aggregate.adoc[]
+include::{includedir}/examples/aggregate.adoc[leveloffset=2]
 
-include::{includedir}/examples/events.adoc[]
+include::{includedir}/examples/events.adoc[leveloffset=2]
 
-include::{includedir}/examples/snapshot.adoc[]
+include::{includedir}/examples/snapshot.adoc[leveloffset=2]
 
-include::{includedir}/examples/queries.adoc[]
+include::{includedir}/examples/queries.adoc[leveloffset=2]
 
-include::{includedir}/examples/joins.adoc[]
+include::{includedir}/examples/joins.adoc[leveloffset=2]
 
-include::{includedir}/examples/frp.adoc[]
+include::{includedir}/examples/frp.adoc[leveloffset=2]
 
-include::{includedir}/diagramming.adoc[]
+include::{includedir}/diagramming.adoc[leveloffset=1]
 
-include::{includedir}/support.adoc[]
+include::{includedir}/support.adoc[leveloffset=1]

grooves-docs/src/docs/asciidoc/intro.adoc

@@ -1,20 +1,20 @@
-== Introduction
+= Introduction
 
 Event Sourcing is a way of storing data for flexible retrieval.
 The principle behind Event Sourcing is very simple.
 We treat our database like a log file.
 It is a record of everything that happened as events, and we read these events in order to compute the state of things like we do while debugging an application from the logs.
 
-=== Event Sourcing Concepts
+== Event Sourcing Concepts
 
 Here are some things that we will need to get familiar with, that are relevant to Event Sourcing.
 
-==== Aggregate
+=== Aggregate
 
 An aggregate is a type of object that you are interested in managing data about.
 A classic example would be a bank account.
 
-==== Event
+=== Event
 
 An event is an atomic change that needs to occur on the aggregate.
 A suitable example for the bank account would be a transaction.
@@ -25,21 +25,21 @@ When there is a `revert` event or a `merge` (which is represented as a `deprecat
 We will not be modifying the aggregate in our data store.
 We will however, store the event in the data store so we know when we read to read it a certain way.
 
-==== Snapshot
+=== Snapshot
 
 A snapshot is a way of looking at the state of an aggregate at a point in time.
 In our banking example, this could be your account balance.
 
-=== CQRS
+== CQRS
 
 Event Sourcing works particularly well with CQRS - Command Query Responsibility Segregation.
 There are a couple of types of objects that are relevant to Event Sourcing and CQRS.
 
-==== Command
+=== Command
 A command is an input which causes one or more events to be stored.
 It typically represents a broad intention of the user.
 
-==== Query
+=== Query
 A query is a computation that needs to be performed in order to obtain a snapshot.
 
 A query performs a computation like the one below.
@@ -63,7 +63,7 @@ S_N = f(S_k, [E_(k+1) .. E_(N)])
 
 The second one holds true only for forward events.
 
-=== Representing Events
+== Representing Events
 
 This is how we'll be representing events in the documentation.
 

grooves-docs/src/docs/asciidoc/support.adoc

@@ -1,4 +1,4 @@
-== Support
+= Support
 
 If you're having trouble using this, head over to https://github.com/rahulsom/grooves/issues[Github Issues] and raise a question.
 Our aim is to document things here rather than answering individual questions on the issue tracker.