Cover by John Ferguson Smart

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

O'Reilly logo

Configuring Your Build Tools

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

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.

Configuring Maven in Jenkins

Figure 4-7. Configuring Maven in Jenkins

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 MAVEN_OPTS variable. 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.

Configuring system-wide MVN_OPTS

Figure 4-8. Configuring system-wide MVN_OPTS

Ant

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.

Configuring Ant in Jenkins

Figure 4-9. Configuring Ant in Jenkins

Shell-Scripting Language

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.

In Windows, the Shell section does not apply—you use Windows batch scripting instead. So, on a Windows build server, you should leave this field blank.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required