Build processes

This chapter covers

■Adding Groovy to Ant builds

■Using Maven with Groovy

■Groovy Grapes and @Grab

■The future: Gradle

Building source code is almost always a pain point in development organizations. An ideal build process is automated end-to-end, including compilation, running tests, generating reports, and producing any required artifacts. The process needs to be fast enough that it can be done frequently, especially given modern agile approaches, and yet flexible enough to adapt to the exigencies of individual teams.

In the Java world two primary approaches to automated builds have emerged over time. Both are open source projects from Apache. The first is Ant (http:// ant.apache.org), which uses a library of tasks configured in XML backed by Java classes. The other is Maven (http://maven.apache.org), which offers a rich array of options and promises to make the entire process simple, but uses a highly opinionated API that requires a degree of mastery to use effectively.

To start I want to address the goals of any build process, and then see how the various tools attempt to meet them.

93

www.it-ebooks.info

5.1The build challenge

A software build combines several features that individually seem like they ought to be easy but in practice become complicated. To build your code you must

■Download any necessary dependencies.

■Compile the source code with the dependencies properly resolved, handling any cross-language issues that may arise.

■Run the unit, integration, and/or functional tests.

■Produce the desired artifacts, whatever they may be.

Optionally, other tasks might include checking code out of source code control, generating documentation, and even deploying the results into production.

The IDE build

Some companies still do their builds inside integrated development environments (IDEs). Although this is not in itself a bad thing, it often leads to long-term problems. Sooner or later such companies wind up with a special computer that no one is allowed to touch, even though the original owner left or transferred to another division long ago, because it’s the only system where the build still works.

Current thinking is that the source code control system should manage all aspects of a build, from the required scripts to the JAR dependencies. That way you can always be sure the build is correct and self-sufficient, which avoids the whole “at least it works on my machine” problem.

Figure 5.1 Guide to technologies in this chapter. Java approaches are based on Ant or Maven. Groovy supplies Ant tasks for compilation and executing scripts. Gant is used by Grails but will eventually be replaced by Gradle. The AntBuilder class is useful and built into Gradle. There are two separate plugins available for Maven builds. Groovy Grapes make it easy to deliver code (normally scripts) to a client without compiling it first. Ultimately, though, the future belongs to Gradle.

www.it-ebooks.info

In fact, the recent trend in development processes is toward continuous delivery, where a single command performs the whole sequence from build to deployment in one motion.1

There are two primary build tools in the Java world: Ant and Maven. Ant is older and is gradually being replaced, but it is still common in the industry and is the foundation of everything that came afterward. Maven is used extensively in the Java industry but tends to trigger strong feelings in developers.

A guide to the technologies covered in this chapter is shown in figure 5.1. I’ll start with the Apache Ant project in the next section.

5.2The Java approach, part 1: Ant

Apache Ant is a Java-based build tool, based on the older “make” technology but without many of its difficulties. The name Ant represents either “another neat tool” or a tool that lifts far more than its own weight, depending on whom you ask. Ant build files are written in XML, so they are inherently cross-platform, and because Java classes implement the XML tasks, a single API suffices for all operating systems.

That’s the good news. The (somewhat) bad news is that Ant is an extremely lowlevel API, so many build files consist of lots of twisty little tasks, all alike.2

Let me start with a “Hello, World” example in the next listing, based on a sample from the Ant tutorial provided by Apache at the Ant website.

Listing 5.1 build.xml: A simple Ant build file for a “Hello, World” Java application

<project name="HelloWorld" basedir="." default="main">

<property name="src.dir" value="src"/> <property name="build.dir" value="build"/>

<property name="classes.dir" value="${build.dir}/classes"/> <property name="jar.dir" value="${build.dir}/jar"/> <property name="main-class" value="mjg.HelloWorld"/>

<target name="clean">

<delete dir="${build.dir}"/> </target>

<target name="compile">

<mkdir dir="${classes.dir}"/>

<javac srcdir="${src.dir}" destdir="${classes.dir}" includeantruntime="false"/>

</target>

<target name="jar" depends="compile"> <mkdir dir="${jar.dir}"/>

<jar destfile="${jar.dir}/${ant.project.name}.jar"

1See Jez Humble and Dave Farley’s book Continuous Delivery (Addison Wesley, 2010) for details. (Available through its companion website, http://continuousdelivery.com/.)

2Yes, an Adventure (or Zork) reference. I just mean they’re small, they’re many, and they’re easy to get lost in.

www.it-ebooks.info

basedir="${classes.dir}"> <manifest>

<attribute name="Main-Class" value="${main-class}"/> </manifest>

</jar>

</target>

<target name="run" depends="jar">

<java jar="${jar.dir}/${ant.project.name}.jar" fork="true"/> </target>

<target name="clean-build" depends="clean,jar"/>

<target name="main" depends="clean,run"/>

</project>

By default, this file is called build.xml and resides in the root directory of the project. The root element of the project file is called <project>, which is given a name, a base directory, and the name of a default task to run if none is supplied on the command line.

At the top of the file a series of properties are set, including the locations of various directories. Note that one property can refer to another by using the ${...} syntax.

A series of <task> elements (clean, compile, jar, run, clean-compile, and main) are defined to represent individual actions during the build process. Some tasks depend on others, which is expressed using the depends attribute of the <task> element.

All the defined tasks ultimately delegate to a library of predefined Ant tasks. Here those tasks include file-based tasks like mkdir and delete, and Java-related tasks like javac, jar, and java.

Executing this build without arguments means typing ant at the command line, which will execute the default main task. Because main depends on clean and run it will execute those tasks first, which will execute their own individual dependencies, and so on. The result looks like the following listing.

Listing 5.2 Execution of the default task in the “Hello, World” Ant build

Buildfile: /.../build.xml clean:

[delete] Deleting directory /.../build compile:

[mkdir] Created dir: /.../build/classes

[javac] Compiling 1 source file to /.../build/classes

jar:

[mkdir] Created dir: /.../build/jar

[jar] Building jar: /.../build/jar/HelloWorld.jar

run:

[java] Hello, World! main:

BUILD SUCCESSFUL Total time: 1 second

www.it-ebooks.info