BATCH-328: applied patch for samples

src/.project

@@ -1,7 +1,18 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <projectDescription>
-	<name>src</name>
+	<name>spring-batch</name>
 	<comment></comment>
 	<projects>
 	</projects>
+	<buildSpec>
+	</buildSpec>
+	<natures>
+	</natures>
+	<linkedResources>
+		<link>
+			<name>pom.xml</name>
+			<type>1</type>
+			<locationURI>SPRING_BATCH/pom.xml</locationURI>
+		</link>
+	</linkedResources>
 </projectDescription>

src/site/apt/articles.apt

@@ -16,3 +16,13 @@ Spring Batch In the Media
   * http://blog.decaresystems.ie/index.php/2007/04/12/spring-batch/
 
   * http://www.itweek.co.uk/itweek/news/2189502/accenture-launches-batch
+
+  * http://www.theserverside.com/tt/articles/article.tss?l=SpringBatchOverview
+
+  * http://www.springframework.org/node/698
+
+  * http://www.infoq.com/interviews/johnson-spring-portfolio
+
+  * http://www.infoq.com/news/2008/06/spring-batch
+
+  * http://blog.springsource.com/main/2008/05/30/running-a-spring-batch-job-in-the-springsource-aplication-platform

src/site/apt/building.apt

@@ -70,9 +70,8 @@ $ mvn test -DforkMode=never -Dtest=FootballJobFunctionalTests -Dplayer.file.name
   and feeds changes into other projects in your workspace.  It is not
   recommended to use the Maven Eclipse plugin (<<<mvn
   eclipse:eclipse>>>) because it cannot track dependencies across the
-  Eclipse workspace.  It will also create conflicting Eclipse
-  meta-data every time you run it, which will interfere with the meta
-  data under source control.
+  Eclipse workspace.  It will also create Eclipse meta-data every time
+  you run it, conflicting with the version under source control.
 
 * Dependencies
 

src/site/apt/cases/index.apt

@@ -29,7 +29,8 @@ Use Cases for Spring Batch
     * {{{parallel.html}Massively Parallel Batch Processing}}.  Spring
     Batch 1.0 does not contain any implementations of this use case,
     but it is quite feasible to implement them using the framework as
-    a starting point.
+    a starting point.  1.1 has some prototype code under the Integration
+    module.
 
     * {{{restart.html}Manual Restart After Failure}}
 

src/site/apt/cases/parallel.apt

@@ -149,7 +149,7 @@ Use Case: Massively Parallel Batch Processing
   Consider two examples: a file input source and a JDBC (SQL query)
   based input source.  Each provides its own challenges.
 
-*** File Data Source Partitioning
+*** File Data Source
 
   * If each node reads the whole file there could be a performance
   issue.  They would all need to have instructions about which lines
@@ -163,16 +163,15 @@ Use Case: Massively Parallel Batch Processing
   * But if each input record can span a variable number of lines (not
   that unlikely in practice), then we can't use line numbers
 
-  * Maybe the best solution is to have a single process parsing the
-  file and sending it to a message queue, either formally using a
-  messaging infrastructure or informally using some sort of
-  roll-your-own approach.  The integration pattern could then be a
+  * Maybe the best solution is to use middleware anyway.  A single
+  process parses the file and sends it to a message queue, item by
+  item (or chunk by chunk).  The integration pattern could then be a
   simple Eager Consumer, assuming that all records are processed
   independently.  The messaging semantics would simply have to ensure
   that a consumer can roll back and return the input records to a
   queue for another consumer to retry.
 
-  For large batches a real messaging infrastructure (JMS etc.) with
+  * For large batches a real messaging infrastructure (JMS etc.) with
   guaranteed delivery would be a benefit, but might be seen as
   overkill for a system that didn't otherwise require it.  In this
   case we could imagine the partitioning process being one of simply
@@ -182,19 +181,15 @@ Use Case: Massively Parallel Batch Processing
 
   * What would parallel processing look like to the client?  We can
   make it completely transparent if we assume that the client only
-  ever implements <<<ItemProvider>>> and <<<ItemProcessor>>>.  The
-  client code is unaware of the partitioning of its data source:
-
-+---
-batchTemplate.iterate(new ItemProviderRepeatCallback(provider, processor));
-+---
+  ever implements <<<ItemReader>>> and <<<ItemWriter>>>.  The
+  client code is unaware of the partitioning of its data source.
 
   * Parallelisation could also take place at the level of the
-  <<<ItemProvider>>> - we could proxy the data provider and wrap it in
+  <<<ItemReader>>> - we could proxy the data provider and wrap it in
   a partitioning proxy:
 
 +---
-<bean id="itemProvider" 
+<bean id="itemReader" 
     class="org.springframework.aop.framework.ProxyFactoryBean">
 
     <property name="target">
@@ -260,7 +255,7 @@ batchTemplate.iterate(new ItemProviderRepeatCallback(provider, processor));
 
 +---
 <bean id="inputSource" 
-    class="test.input.SqlInputDataProvider">
+    class="test.input.SqlInputItemReader">
 
     <property name="query">
         <value>SELECT * from T_INPUT</value>