Easiest way to get started: deploy the sample. It's a regular war file. Once it's deployed, browse with a web browser (e.g. localhost:8080/spring-batch-admin-sample) and check out the features for launching jobs and inspecting job executions.
Ways to get the code:
<dependency> <groupId>org.springframework.batch</groupId> <artifactId>spring-batch-admin-manager</artifactId> <version>2.0.0.M1</version> </dependency>
For snapshots, add a repository location:
<repository> <id>spring-snapshots</id> <name>Spring Maven Snapshot Repository</name> <url>http://s3.amazonaws.com/maven.springframework.org/snapshot</url> </repository>
Just execute a job (e.g. from command line) against the same database that is used by Spring Batch Admin, and the UI picks up the meta data from the usual Spring Batch tables.
Include Spring XML files in META-INF/spring/batch/jobs. Each file should be self-contained (except for Batch execution components like the jobRepository which are provided centrally), and carry one or more bean definitions for a Spring Batch Job. When the application starts these files are scanned and loaded as child contexts, and then the jobs are registered with a JobRegistry in the parent. Because they are child contexts you don't have to worry about name clashes between different XML files or different contributing JARs (except for the jobs which must have unique names, at present, but perhaps not when we get to a release).
As a convenience, the child contexts inherit property placeholders and AOP configuration from the parent (this is not the default behaviour for a child context). This means you can control those things centrally if you need to. Of course, the child can always create its own placeholder definition and AOP configuration, but these will not affect the parent or any of its siblings.
The most likely thing you will want to customize is the location of the database. Spring Batch Admin ships with an embedded HSQLDB database, which is initialized on start up.
The system tries to provide some useful defaults for things like transaction manager, job repository, job registry etc. Most of these live in the manager jar in a special place: META-INF/spring/batch/bootstrap. If you want to override them, just add your own versions of the same bean definitions to a Spring XML config file in META-INF/spring/batch/override (these are guaranteed to load after the bootstrap files, so they can override default definitions). You could use this to override the data source definition as an alternative to the environment settings described above.
Hints for custom applications: