Corrected errors in docs and removed index-pdf.adoc

index-pdf.adoc was  a duplicate of index-single.adoc.   And thus was not necessary
The errors corrected were identified in https://github.com/spring-projects/spring-batch/pull/429

Resolves BATCH-2632

spring-batch-docs/asciidoc/index-pdf.adoc

@@ -1,39 +0,0 @@
-:doctype: book
-:toc:
-:toclevels: 4
-
-include::header/index-header.adoc[]
-
-include::spring-batch-intro.adoc[]
-
-include::whatsnew.adoc[]
-
-include::domain.adoc[]
-
-include::job.adoc[]
-
-include::step.adoc[]
-
-include::readersAndWriters.adoc[]
-
-include::scalability.adoc[]
-
-include::repeat.adoc[]
-
-include::retry.adoc[]
-
-include::testing.adoc[]
-
-include::common-patterns.adoc[]
-
-include::jsr-352.adoc[]
-
-include::spring-batch-integration.adoc[]
-
-include::appendix.adoc[]
-
-include::schema-appendix.adoc[]
-
-include::transaction-appendix.adoc[]
-
-include::glossary.adoc[]

spring-batch-docs/asciidoc/repeat.adoc

@@ -63,13 +63,13 @@ The simplest general purpose implementation of
 ----
 RepeatTemplate template = new RepeatTemplate();
 
-template.setCompletionPolicy(new FixedChunkSizeCompletionPolicy(2));
+template.setCompletionPolicy(new SimpleCompletionPolicy(2));
 
 template.iterate(new RepeatCallback() {
 
-    public ExitStatus doInIteration(RepeatContext context) {
+    public RepeatStatus doInIteration(RepeatContext context) {
         // Do stuff in batch...
-        return ExitStatus.CONTINUABLE;
+        return RepeatStatus.CONTINUABLE;
     }
 
 });
@@ -77,7 +77,7 @@ template.iterate(new RepeatCallback() {
 
 In the example we return `RepeatStatus.CONTINUABLE` to
     show that there is more work to do. The callback can also return
-    `ExitStatus.FINISHED` if it wants to signal to the caller that
+    `RepeatStatus.FINISHED` if it wants to signal to the caller that
     there is no more work to do. Some iterations can be terminated by
     considerations intrinsic to the work being done in the callback, others
     are effectively infinite loops as far as the callback is concerned and the
@@ -112,7 +112,7 @@ A `RepeatContext` will have a parent context
       Spring Batch to indicate whether processing has finished. These are
       possible `RepeatStatus` values:
 
-.ExitStatus Properties
+.RepeatStatus Properties
 
 |===============
 |__Value__|__Description__
@@ -295,12 +295,12 @@ The example above uses a default
     `RepeatTemplate` into the interceptor.
 
 If the intercepted method returns `void` then the
-    interceptor always returns `ExitStatus.CONTINUABLE` (so there is a danger of
+    interceptor always returns `RepeatStatus.CONTINUABLE` (so there is a danger of
     an infinite loop if the `CompletionPolicy` does not
     have a finite end point). Otherwise it returns
-    `ExitStatus.CONTINUABLE` until the return value from the
+    `RepeatStatus.CONTINUABLE` until the return value from the
     intercepted method is null, at which point it returns
-    `ExitStatus.FINISHED`. So the business logic inside the target
+    `RepeatStatus.FINISHED`. So the business logic inside the target
     method can signal that there is no more work to do by returning
     `null`, or by throwing an exception that is re-thrown by the
     `ExceptionHandler` in the provided

spring-batch-docs/asciidoc/retry.adoc

@@ -24,7 +24,7 @@ To make processing more robust and less prone to failure, sometimes
     succeed on a subsequent attempt. Errors that are susceptible to this kind
     of treatment are transient in nature. For example a remote call to a web
     service or RMI service that fails because of a network glitch or a
-    `DeadLockLoserException` in a database update may
+    `DeadlockLoserDataAccessException` in a database update may
     resolve themselves after a short wait. To automate the retry of such
     operations Spring Batch has the `RetryOperations`
     strategy. The `RetryOperations` interface looks like

spring-batch-docs/asciidoc/scalability.adoc

@@ -352,13 +352,13 @@ The names of the step executions (the keys in the
       this convention.
 
 An optional interface
-      `PartitioneNameProvider` can be used to
+      `PartitionNameProvider` can be used to
       provide the partition names separately from the partitions
       themselves.  If a Partitioner implements
       this interface then on a restart only the names will be queried.
       If partitioning is expensive this can be a useful optimisation.
       Obviously the names provided by the
-      `PartitioneNameProvider` must match those
+      `PartitionNameProvider` must match those
       provided by the `Partitioner`.
 
 [[bindingInputDataToSteps]]