Build tools are the bread-and-butter of any build server, and Jenkins is no exception. Out of the box, Jenkins supports three principal build tools: Ant, Maven, and the basic shell-script (or Batch script in Windows). Using Jenkins plugins, you can also add support for other build tools and other languages, such as Gant, Grails, MSBuild, and many more.
Maven is a high-level build scripting framework for Java that uses notions such as a standard directory structure and standard life cycles, Convention over Configuration, and Declarative Dependency Management to simplify a lot of the low-level scripting that you find in a typical Ant build script. In Maven, your project uses a standard, well-defined build life cycle—compile, test, package, deploy, and so forth. Each life cycle phase is associated with a Maven plugin. The various Maven plugins use the standard directory structure to carry out these tasks with a minimum of intervention on your part. You can also extend Maven by overriding the default plugin configurations or by invoking additional plugins.
Jenkins provides excellent support for Maven, and has a good understanding of Maven project structures and dependencies. You can either get Jenkins to install a specific version of Maven automatically (as we are doing with Maven 3 in the example), or provide a path to a local Maven installation (see Figure 4-7). You can configure as many versions of Maven for your build projects as you want, and use different versions of Maven for different projects.
If you tick the Install automatically checkbox, Jenkins will download and install the requested version of Maven for you. You can either ask Jenkins to download Maven directly from the Apache site, or from a (presumably local) URL of your choice. This is an excellent choice when you are using distributed builds, and, since Maven is cross-platform, it will work on any machine. You don’t need to install Maven explicitly on each build machine—the first time a build machine needs to use Maven, it will download a copy and install it to the tools directory in the Jenkins home directory.
Sometimes you need to pass Java system options to your Maven build
process. For instance it is often useful to give Maven a bit of extra
memory for heavyweight tasks such as code coverage or site generation.
Maven lets you do this by setting the
In Jenkins, you can set a system-wide default value, to be used across
all projects (see Figure 4-8). This comes
in handy if you want to use certain standard memory options (for
example) across all projects, without having to set it up in each
project by hand.
Ant is a widely-used and very well-known build scripting language for Java. It is a flexible, extensible, relatively low-level scripting language, used in a large number of open source projects. An Ant build script (typically called build.xml) is made up of a number of targets. Each target performs a particular job in the build process, such as compiling your code or running your unit tests. It does so by executing tasks, which carry out a specific part of the build job, such as invoking javac to compile your code, or creating a new directory. Targets also have dependencies, indicating the order in which your build tasks need to be executed. For example, you need to compile your code before you can run your unit tests.
Jenkins provides excellent build-in support for Ant—you can invoke Ant targets from your build job, providing properties to customize the process as required. We look at how to do this in detail later on in this book.
If Ant is available on the system path, Jenkins will find it. However, if you want to know precisely what version of Ant you are using, or if you need to be able to use several different versions of Ant on different build jobs, you can configure as many installations of Ant as required (see Figure 4-9). Just provide a name and installation directory for each version of Ant in the Ant section of the Configure System screen. You will then be able to choose what version of Ant you want to use for each project.
If you tick the Install automatically checkbox, Jenkins will download and install Ant into the tools directory of your Jenkins home directory, just like it does for Maven. It will download an Ant installation the first time a build job needs to use Ant, either from the Apache website or from a local URL. Again, this is a great way to standardize build servers and make it easier to add new distributed build servers to an existing infrastructure.
If you are running your build server on Unix or Linux, Jenkins lets you insert shell scripts into your build jobs. This is handy for performing low-level, OS-related tasks that you don’t want to do in Ant or Maven. In the Shell section, you define the default shell that will be used when executing these shell scripts. By default, this is /bin/sh, but there are times you may want to modify this to another command interpreter such as bash or Perl.