Appendix A. Setting up the development environment

This appendix shows you how to set up your development environment. We begin with Apache Maven 3: installing Maven and using basic commands. We then create a new Maven project from scratch and add the necessary dependencies for Spring Batch. We also explore Spring Batch features from the SpringSource Tool Suite for Eclipse and learn how to set up a Spring Batch project quickly from a blank Maven project and use the Spring Batch development tools.

A.1. Apache Maven 3

Apache Maven provides build tools, documentation, dependency management, and reporting for your projects. One of the benefits of Maven is to promote standards and conventions that accelerate the development cycle. At the heart of all Maven projects is the POM—the Project Object Model—represented in a pom.xml file. The POM contains general project information like name, version, dependencies, and plug-in descriptions.

First, we install Maven and learn some basic commands. We then create a new Maven project from scratch and configure it to use Spring Batch.

 

Note

For more information about Maven, visit http://maven.apache.org.

 

A.1.1. Installation

Maven is a Java program, so you need Java on your computer to be able to run it. To check that your computer has the Java SDK (software development kit) installed and available, run the command java -version; you should see this output:

% java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

The java -version command shows you the Java version in detail. At the time of this writing, the latest version of Apache Maven is 3.0.3.

 

Note

Maven 3 requires a Java 5 SDK installed (a JRE isn’t sufficient).

 

You can download Maven 3 from its official website: http://maven.apache.org. It comes as an archive file that creates an apache-maven-3.0.3 directory where it’s extracted. You then need to create an M2_HOME environment variable that contains the directory where you installed Maven 3. To make the mvn command available in your shell, add M2_HOME/bin to your PATH environment variable: use $M2_HOME/bin if you’re using a UNIX/Linux-based OS; use %M2_HOME%in for Windows.

You can check that you installed Maven properly by running the mvn–version command, which outputs information about your system:

% mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /home/acogoluegnes/bin/apache-maven-3.0.3
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/acogoluegnes/bin/jdk1.6.0_26/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.38-8-generic", arch: "amd64",
   family: "unix"

The output you get will differ, but it ensures that Maven is correctly installed on your computer. Now that you’ve installed Maven, let’s use it! But before we look at the Maven command line, let’s go over some concepts.

A.1.2. Understanding Maven

Maven uses the concept of a build lifecycle, where the three built-in build lifecycles are default, clean, and site.

  • Default —Handles project deployment
  • Clean —Handles project cleaning
  • Site —Handles the creation of site documentation

Each build lifecycle consists of an ordered list of build phases. For example, the default lifecycle has the following phases, in this order: validate, compile, test, package, integrationtest, verify, install, and deploy. When you run a given phase, all prior phases run before it in sequence. For example, if you run install, phases from validate to verify run first. A build phase consists of goals, where a goal represents a task smaller than a build phase. For example, the Maven Clean plug-in contributes to the clean phase with a goal named clean. Also, note that Maven uses two phases by default: clean and site.

To get some basic help, run the following command:

% mvn --help
usage: mvn [options] [<goal(s)>] [<phase(s)>]

Table A.1 lists some common and useful Maven commands.

Table A.1. Common Maven commands

Maven command

Description

mvn clean Deletes all build output, usually the target directory
mvn test Compiles main and test source trees and runs unit tests
mvn clean package Cleans, compiles, tests, and packages the project
mvn clean install Cleans, compiles, tests, and produces an artifact like a JAR file or a WAR file, and installs it in the local repository
mvn clean install -P bootstrap As above but using a bootstrap profile

Thanks to its build lifecycles, phases, and goals, Maven commands are the same whatever the project. Developers are no longer lost.

Next, we look at the steps necessary to create a blank Maven project from scratch. We’ll then add the necessary dependencies before importing the project in the SpringSource Tool Suite.

A.1.3. Creating a blank project

In this section, we create a blank Maven project, a necessary step before making the project Spring Batch–powered. Maven includes features to generate projects using an archetype. An archetype is a project template that contains model files like pom.xml and a standard directory tree.

On UNIX/Linux-based systems:

% mvn archetype:generate 
  -DarchetypeArtifactId=maven-archetype-quickstart 
  -DarchetypeVersion=1.1 
  -DgroupId=com.manning.sbia 
  -DartifactId=appA 
  -Dversion=1.0-SNAPSHOT 
  -Dpackage=com.manning.sbia.appA

On Windows:

mvn archetype:generate ^
  -DarchetypeArtifactId=maven-archetype-quickstart ^
  -DarchetypeVersion=1.1 ^
  -DgroupId=com.manning.sbia ^
  -DartifactId=appA ^
  -Dversion=1.0-SNAPSHOT ^
  -Dpackage=com.manning.sbia.appA

To create a new project, you use the maven archetype plug-in. This command generates an empty project based on the Maven file and directory layout. Maven creates the project in the appA directory (the name of the project). The project contains a couple of Java classes; you can delete them and create directories to make your project look like the following:

appA/
  pom.xml
  src/
    main/
      java/
      resources/
    test/
      java/
      resources/

The previous snippet shows Maven’s standard project structure. If you follow this structure, Maven will know automatically where to find Java classes, test classes, and so on. Hurrah for convention over configuration!

You have your Maven project—this is great, but it’s empty. If you were to develop some Spring Batch inside the project, Maven wouldn’t be able to compile your code. This is because you need to add Spring Batch dependencies, so let’s see how to add them.

A.1.4. Adding Spring Batch dependencies to the Maven project

There’s nothing related to Spring Batch in your blank Maven project, so you need to add these dependencies inside the pom.xml file. Maven downloads all dependencies from internet repositories, so you don’t have to worry about hunting the JAR files from multiple websites. The following listing shows the content of the pom.xml file once you add the Spring Batch dependencies.

Listing A.1. The pom.xml file Spring Batch dependencies

You define a spring.batch.version property because you’ll need the Spring Batch version in several places. It’s more convenient to define a property once and then refer to it. You also set up maven.compiler properties the for the Java compiler. You then add Spring Batch dependencies . Note the use of the version property and the exclusion of the Apache Commons Logging dependency. As soon as you refer to a dependency—Spring Batch, in our case—Maven downloads all transitive dependencies. Commons Logging would come as a transitive dependency of the Spring Framework, and you don’t want it: that’s why you exclude it with the exclusion element (more on logging later). At you add the Spring Batch test module. Chapter 14 introduces you to this test module, but you can still test your Spring Batch jobs without it (import the dependency only if you need it). You use the scope element for the test dependency. With the scope element set to test, Maven adds the corresponding dependency only for compiling and running tests.

You now have the bare minimum to use Spring Batch, but you need to add some other dependencies to make the case study from chapter 1 work.

Adding Spring Dependencies

Spring Batch 2.1 is compatible with both Spring 2.5 and Spring 3.0, but it pulls Spring 2.5 dependencies by default. We use Spring 3.0 in this book, so you should add the dependencies listed in table A.2 to your pom.xml.

Table A.2. Spring dependencies to add to the pom.xml file

Group ID

Artifact ID

Version

org.springframework spring-beans 3.0.5.RELEASE
org.springframework spring-context 3.0.5.RELEASE
org.springframework spring-core 3.0.5.RELEASE
org.springframework spring-jdbc 3.0.5.RELEASE
org.springframework spring-tx 3.0.5.RELEASE

By using Spring 3.0, you’ll benefit from the latest bug fixes and from features like the jdbc namespace to easily create an in-memory database—handy for testing—or Representational State Transfer (REST) support. Let’s now see about the logging dependencies.

Adding Logging Dependencies

Logging to the console or a file is useful: it can help with debugging. You can add your own logging statements in your code, but all the frameworks—including Spring Batch—produce their own logging messages. Logging can be complicated to set up in Java. For the full story, look at the sidebar about logging; for the short story, add the dependencies listed in table A.3.

Table A.3. Logging dependencies to add to the pom.xml file

Group ID

Artifact ID

Version

org.slf4j slf4j-api 1.6.1
org.slf4j jcl-over-slf4j 1.6.1
ch.qos.logback logback-classic 0.9.29

 

Logging in Spring Batch

Let’s face it: logging in Java is a mess. There are standards, de facto standards, and several logging façades. How can a beginner sort this out? Covering logging and logging configuration best practices is beyond the scope of this book. To make it short, we use SLF4J as a façade, the implementation of Apache Commons Logging over SLF4, and Logback as the SLF4J implementation. For a thorough explanation of the logging configuration in Spring Batch—and in Spring in general—take a look at this blog entry: http://blog.springsource.com/2009/12/04/logging-dependencies-in-spring/.

 

As you can see from table A.3, we’re using Logback as the logging implementation. It needs a configuration file: logback-test.xml, which you can create in src/test/ resources. The following listing shows the content of the logback-test.xml file.

Listing A.2. Configuring Logback in logback-test.xml
<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>
        %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
      </pattern>
   </encoder>
  </appender>

<logger name="org.springframework.batch" level="warn" />

  <root level="error">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

The logback-test.xml file is okay for a test configuration, but you should have a look at the Logback documentation for a more production-oriented configuration.

We’re done with logging dependencies; let’s now configure dependencies that the case study uses.

Adding Dependencies for the Case Study

Chapter 1 introduces the case study: the batch job for the online store application. The batch job uses Apache Commons IO to deal with decompressing the input ZIP archive and H2, the Java database. Table A.4 lists the dependencies that the study uses.

Table A.4. Case study dependencies to add to the pom.xml file

Group ID

Artifact ID

Version

commons-io commons-io 2.0.1
com.h2database h2 1.3.156

We’re getting close to the end of the dependencies: next, we test dependencies!

Adding Test Dependencies

We use JUnit and the Spring TestContext Framework to write an integration test for our case study batch job. Table A.5 lists the corresponding dependencies.

Table A.5. Test dependencies to add to the pom.xml file

Group ID

Artifact ID

Version

junit junit 4.8.2
org.springframework spring-test 3.0.5.RELEASE

Don’t forget to use the test scope for these dependencies! We’re done with the dependencies: your Maven project is ready to compile and launch Spring Batch jobs. But are you going to use a text editor to write these jobs? Surely not. Now that your Maven project is all set up, you can start using a full-blown IDE—with some Spring and Spring Batch support—to write your jobs: the SpringSource Tool Suite for Eclipse.

A.2. The SpringSource Tool Suite for Eclipse

The SpringSource Tool Suite (STS) is an Eclipse-based IDE. The focus of STS is to provide tools to help Spring developers create and manage Spring-based applications. STS offers tools to edit XML Spring contexts using a completion editor and wizards to facilitate project creation. STS also includes Groovy, Grails, and OSGi tools. You can download STS from www.springsource.com/products/springsource-tool-suite-download.

 

Note

You don’t need a specific IDE to work on a Spring Batch project. STS is free and provides some nice tooling for Spring and Spring Batch. That’s why we use it, but you could use NetBeans or IntelliJ IDEA on a Spring Batch project as well. It’s also worth mentioning that you can install STS’s tooling on top of an existing Eclipse installation (instead of downloading STS as a bundle) because it’s a set of plug-ins.

 

This section covers how to import a Maven project into STS and use the tooling to create a Spring Batch job.

A.2.1. Importing the Spring Batch project

STS has built-in support for Maven, so you can easily import the Maven project you created in section A.1 with STS. You’ll end up with a ready-to-edit project, with configuration managed by the STS-Maven integration plug-in.

To import the Maven-based Spring Batch project in STS, choose File > Import > Maven and Existing Maven Projects. You can then browse to the project directory and click on Finish, as figure A.1 shows.

Figure A.1. STS can import a Maven project. STS then configures the project by using the project POM.

Once created, the project shows up in the Eclipse workspace with a Maven layout, as figure A.2 illustrates.

Figure A.2. The blank Maven project imported in STS. STS automatically includes the dependencies specified in the POM.

The project is now in the STS workspace. Let’s see how to create and edit a Spring configuration file.

A.2.2. Creating and editing a Spring configuration file

Spring Batch configuration relies on Spring configuration. STS has first-class support to manage Spring configuration files. This support includes a wizard to create a Spring file, namespace management, code completion (Ctrl-Space works in Spring XML files!), and much more. STS also provides a nice visualization tool for Spring Batch jobs. Let’s explore all of this now.

You start by using a wizard to create a Spring configuration file. From the package explorer, right-click the src/main/resources source directory and select New > Spring Bean Configuration File. Use the file import-products-job-context.xml and click Next. You can then choose the namespaces you want to include. Include the batch namespace, as figure A.3 shows, and then click Finish.

Figure A.3. When creating a Spring configuration file with the wizard, STS lets you choose which XML namespaces you want to include in the file declaration. You can also change the namespaces once the wizard creates the file, on the Namespaces tab.

Once the Spring configuration file is created, you can select and edit it, as shown in figure A.4. The editor validates the syntax and provides code completion.

Figure A.4. The XML editor for Spring configuration files is arguably STS’s most useful tool for the Spring developer. It provides validation, code completion, and graphical visualization for Spring Batch.

You’re now ready to create a Spring Batch job: use the batch namespace to declare the job, steps, your item reader and writer, and so on. You can then visualize the Spring Batch job by choosing the Batch-Graph tab in the editor. Figure A.5 shows the Spring Batch graphical editor.

Figure A.5. Visualizing a Spring Batch job inside STS, thanks to the Batch-Graph tab. You can also edit the job definition by dragging components from the left to the main editor area. You can edit each component by double-clicking it.

STS speeds up Spring Batch development by offering useful tools, particularly the Spring Batch visual development tool.

A.3. Summary

In this appendix, we set up Maven and Eclipse development environments for Spring Batch applications. We introduced Maven, installed it, and learned its basic commands. Using a simple Maven archetype, we created a blank project and added the necessary dependencies for Spring Batch development.

Finally, we saw how the STS for Eclipse facilitates Spring Batch application development. We used STS to import the Maven project and to create and edit a Spring configuration file for a Spring Batch project.

Appendix B shows how to install Spring Batch Admin, the web-based administration console for Spring Batch.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.20.68