More updates

developer/src/docs/asciidoc/gettingStarted.adoc

@@ -30,7 +30,7 @@ To install the jar files for the various subprojects into your local Maven repos
 The project is essentially a multi-project Gradle build. There is a core API and then subprojects that implement that API. The core API subprojects include:
 
 * `grails-datastore-core` - The core API, this provides core interfaces for implementing a GORM provider
-* `grails-datastore-gorm` - The runtime meta-programming and AST transformation infrastructure behind GORM. Also provide end users with APIs like `grails.gorm.CriteriaBuilder` and `grails.gorm.DetachedCriteria`
+* `grails-datastore-gorm` - The runtime meta-programming and AST transformation infrastructure behind GORM. This also provides end users with APIs like `grails.gorm.CriteriaBuilder` and `grails.gorm.DetachedCriteria`
 * `grails-datastore-gorm-support` - Support classes for easing the writing of a GORM plugin for Grails
 * `grails-datastore-gorm-tck` - The TCK that includes hundreds of Spock specifications that a GORM implementation will need to pass
 * `grails-datastore-web` - Classes required to integrate GORM into a web tier

developer/src/docs/asciidoc/stepByStep.adoc

@@ -1,4 +1,4 @@
-To get started with your new GORM implementation the following steps are required:
+To get started with a new GORM implementation, the following steps are required:
 
 
 === Initial Directory Creation

developer/src/docs/asciidoc/testing.adoc

@@ -41,9 +41,9 @@ class Setup {
 }
 ----
 
-Some setup code has been omitted for clarity, but essentially, the Setup.groovy class should initialize the Datastore and return a Session from the static setup method, which is passed a list of classes to be configured.
+Some setup code has been omitted for clarity, but essentially, the `Setup.groovy` class should initialize the `Datastore` and return a `Session` from the static setup method, which is passed a list of classes to configure.
 
-With this setup, all the TCK tests will be executed against the subproject. If a specific test cannot be implemented due to the underlying datastore lacking support for a particular feature, you can create a test with the same name as the failing test, and it will override the corresponding test in the TCK.
+With this setup, all the TCK tests will be run against the subproject. If a specific test cannot be implemented due to the underlying datastore lacking support for a particular feature, you can create a test with the same name as the failing test, and that will then override the corresponding test in the TCK.
 
 For example: SimpleDB doesn't support pagination. Add a `grails.gorm.tests.PagedResultSpec` class that overrides the one from the TCK. Each test is a Spock specification and Spock has an `Ignore` annotation that can be used to ignore a particular test:
 

developer/src/docs/asciidoc/understandingApi.adoc

@@ -1,7 +1,7 @@
 
 === Introduction
 
-The GORM Developer API is divided into a low-level API that implementers must implement for each specific datastore, and a set of higher-level APIs that enhance domain classes with features visible to regular users, such as dynamic finders, criteria queries, and so on.
+The GORM Developer API is divided into a low-level API that implementors must implement for each specific datastore, and a set of higher-level APIs that enhance domain classes with features visible to regular users, such as dynamic finders, criteria queries, and so on.
 
 The low-level API classes are located within the `grails-datastore-core` subproject, whereas the higher-level APIs used to enhance domain classes can be found in `grails-datastore-gorm`. In this section, we will discuss the low-level API.
 

developer/src/docs/asciidoc/understandingApi/gormApis.adoc

@@ -36,7 +36,7 @@ And then add a `src/main/resources/META-INF/services/org.grails.compiler.gorm.Go
 org.grails.datastore.gorm.neo4j.Neo4jEntityTraitProvider
 ----
 
-GORM will automatically inject the trait into any domain class discovered in `grails-app/domain` or annotated with the `Entity` annotation. However, if Hibernate is present in the classpath, you must inform GORM to map the domain class with Neo4j:
+GORM will automatically inject the trait into any domain class discovered in `grails-app/domain` or annotated with the `Entity` annotation. However, if Hibernate is present on the classpath, you must inform GORM to map the domain class with Neo4j:
 
 [,groovy]
 ----

developer/src/docs/asciidoc/understandingApi/implementingCrud.adoc

@@ -190,4 +190,4 @@ protected void deleteEntries(String family, final List<Object> keys) {
 }
 ----
 
-You'll notice that this implementation uses a `MongoQuery` instance. Also, it's important to note that when implementing an `EntityPersister`, you enable basic CRUD operations but not querying. The latter is a subject we'll explore in the following sections. However, before delving into that, we need to cover secondary indices, as they are required for querying.
+You'll notice that this implementation uses a `MongoQuery` instance. Also, it's important to note that when implementing an `EntityPersister`, you enable basic CRUD operations, but not querying. The latter is a subject we'll explore in the following sections. However, before delving into that, we need to cover secondary indices, as they are required for querying.

developer/src/docs/asciidoc/understandingApi/implementingQueries.adoc

@@ -56,7 +56,7 @@ Collection executeSubQueryInternal(criteria, criteriaList) {
 }
 ----
 
-Note that if a `Junction` is encountered (representing AND, OR, or NOT), the method recursively handles the junctions. Otherwise, it obtains and executes a handler for the `Criterion` class. The `handlers` map is a map of `Criterion` classes to query handlers. The implementation for `Equals` appears as follows:
+Note that if a `Junction` is encountered (representing AND, OR, or NOT), the method recursively handles the junctions. Otherwise, it obtains and executes a handler for the `Criterion` class. The `handlers` map is a map of `Criterion` class to query handlers. The implementation for `Equals` appears as follows:
 
 [source,groovy]
 ----

rx/src/docs/asciidoc/associations/lazyLoadingSingleEnded.adoc

@@ -17,7 +17,7 @@ This is traditionally how most blocking object mapping implementations have work
 
 [source,groovy]
 ----
-for (book in books) {
+for (Book book in books) {
     println "Author: ${book.author.name}"
 }
 ----
@@ -26,7 +26,7 @@ In the above example RxGORM has no choice but to block in order to load the asso
 
 [source,groovy]
 ----
-for (book in books) {
+for (Book book in books) {
     book.author.subscribe { Author author ->
         println "Author: ${author.name}"
     }

rx/src/docs/asciidoc/gettingStarted/CRUD.adoc

@@ -50,9 +50,9 @@ To update an instance after retrieving it you can use the https://reactivex.io/R
 [source,groovy]
 ----
 Book.get(id)
-    .switchMap() { Book it ->
-        it.title = "The Shining"
-        it.save()
+    .switchMap() { Book book ->
+        book.title = "The Shining"
+        book.save()
     }.subscribe { Book updated ->
         println "Book updated!"
     }

rx/src/docs/asciidoc/introduction.adoc

@@ -4,7 +4,7 @@ Async features were added in GORM 4, however these are merely a way to isolate y
 
 RxGORM builds on top of https://reactivex.io[RxJava] and provides a completely non-blocking, stateless implementation of GORM.
 
-Currently, only MongoDB is supported as a backing store. However, implementations are planned for SQL, REST client and other NoSQL data stores in the future (subject to driver support).
+Currently, only MongoDB is supported as a backing store. However, implementations are planned for SQL, REST client and other NoSQL datastores in the future (subject to driver support).
 
 == Getting Started
 

whatsNew/src/docs/asciidoc/index.adoc

@@ -1,6 +1,6 @@
-= Discover What's Exciting in GORM 8!
 :author: Puneet Behl
-:source-highlighter: coderay
+
+= Discover What's Exciting in GORM 8!
 
 == GORM 8 Unleashed: Embracing Java 11