Fix failing FlatFileItemWriterTests#testWriteWithDelete caused by
not closing reader properly.
Updated some links which weren't working
Merge pull request #83 from juzerali/links

Updated some links which weren't working
BATCH-1929: Convert deprecated classes from the org.springframework.jdbc.core.simple package in core-tests
Merge pull request #82 from adrianshum/master

Fixing failing testWriteWithDelete test in FlatFileItemWriterTests
Merge pull request #85 from chrisjs/BATCH-1929

BATCH-1929: Convert deprecated classes from the org.springframework.jdbc.core.simple package in core-tests
BATCH-1919: Switch to using <jdbc:/> namespace in samples
Merge pull request #91 from chrisjs/BATCH-1919

* BATCH-1919:
  BATCH-1919: Switch to using <jdbc:/> namespace in samples
BATCH-1931: Convert deprecated classes from the org.springframework.jdbc.core.simple package in infrastructure-tests
Merge pull request #88 from chrisjs/BATCH-1931

* BATCH-1931:
  BATCH-1931: Convert deprecated classes from the org.springframework.jdbc.core.simple package in infrastructure-tests
BATCH-1923: add stop() methods to FlowBuilder
BATCH-1928: Convert deprecated classes from the org.springframework.jdbc.core.simple package in samples
BATCH-1928: Converted to using JdbcOperations over JdbcTemplate
Merged pull request 84 from chrisjs/BATCH-1928

* BATCH-1928:
  BATCH-1928: Converted to using JdbcOperations over JdbcTemplate
  BATCH-1928: Convert deprecated classes from the org.springframework.jdbc.core.simple package in samples
BATCH-1923: Fixed javadoc errors
Merge pull request #92 from dsyer/BATCH-1923

* BATCH-1923:
  BATCH-1923: Fixed javadoc errors
  BATCH-1923: add stop() methods to FlowBuilder
BATCH-1918: First effort at @EnableBatchProcessing

Example:

    @Configuration
    @EnableBatchProcessing
    public class RetrySampleConfiguration {

      @Autowired
      private JobBuilderFactory jobs;

      @Autowired
      private StepBuilderFactory steps;

      @Bean
      public Job retrySample() throws Exception {
        return jobs.get("retrySample").start(step()).build();
      }

      @Bean
      protected Step step() throws Exception {
        return steps.get("step").<Trade, Object> chunk(1).reader(reader()).writer(writer()).faultTolerant()
          .retry(Exception.class).retryLimit(3).build();
      }

      @Bean
      protected ItemReader<Trade> reader() {
        GeneratingTradeItemReader reader = new GeneratingTradeItemReader();
        reader.setLimit(10);
        return reader;
      }

      @Bean
      protected ItemWriter<Object> writer() {
        return new RetrySampleItemWriter<Object>();
      }

    }
BATCH-1918: Fixed javadoc errors
Merge pull request #80 from dsyer/BATCH-1918

* BATCH-1918:
  BATCH-1918: Fixed javadoc errors
  BATCH-1918: First effort at @EnableBatchProcessing
Added the concept of a StepRegistry that tracks the Step instance attached to a Job.

- Added a simple MapStepRegistry that keeps track of the step in a simple map per job
- MapJobRegistry implements StepRegistry as well using the delegate pattern
- DefaultJobLoader makes sure to initialize both registries now. Auto-detects that the JobRegistry implements StepRegistry
- JobSupport now implements StepLocator so that such job can be loaded by the DefaultJobLoader
- Also registering any "detached" step available for a particular job to that job if that wasn't done yet. Since a partition handler may link to any step by name, the step registry must be filled with any step that are available in the context of a job. If each job is located in its own application context, this is just fine. If more than one job is defined in the same context, the step registry may be able to return a step that is not related to that job but it shouldn't hurt as this happens only if a component is explicitly asking to execute a step by name for a particular job.