The Evolution of ANT Build Systems Shane McIntosh, Bram Adams and Ahmed E. Hassan Software Analysis and Intelligence Lab (SAIL) School of Computing, Queen’s University, Canada fmcintosh, bram, [email protected] Abstract—Build systems are responsible for transforming The core build machinery, which is hidden behind an intri- static source code artifacts into executable software. While cate facade, has evolved into a highly complex build system build systems play such a crucial role in software development that requires considerable effort to maintain [3]. Third, the and maintenance, they have been largely ignored by software evolution researchers. With a firm understanding of build maintenance of the KDE 3 project’s build system was such a system aging processes, project managers could allocate per- burden that it drastically impacted the productivity of KDE sonnel and resources to build system maintenance tasks more developers, and even warranted migration to a new build effectively, reducing the build maintenance overhead on regular technology, requiring a substantial investment of effort [4]. development activities. In this paper, we study the evolution Despite the crucial role of build systems and their non- of ANT build systems from two perspectives: (1) a static perspective, where we examine the build system specifications trivial maintenance effort, software engineering research using software metrics adopted from the source code domain; rarely focuses on them. Initial findings have shown that the and (2) a dynamic perspective where representative sample size and complexity of build systems grow over time [3, 5], build runs are conducted and their output logs are analyzed. yet this evolution has only been studied in two make-based Case studies of four open source ANT build systems with a build systems. In this paper, we present an empirical study combined history of 152 releases show that not only do ANT build systems evolve, but also that they need to react in an of traditional source code evolution phenomena in four build agile manner to changes in the source code. systems. We address the following two research questions: RQ1) Do the static size and complexity of source code and I. INTRODUCTION build system evolve similarly? Static code analysis of build system specifications Software build systems are responsible for automatically indicates not only that build systems follow linear or transforming the source code of a software project into a exponential evolution patterns in terms of size and collection of deliverables such as executables and develop- complexity, but also that such patterns are highly ment libraries. Such a build process may involve hundreds correlated with the evolution of the source code. of command invocations that must be executed in a specific RQ2) Does the perceived build-time complexity evolve? order to correctly produce a set of deliverables. First, the Build-time complexity measures the perceived com- build tools and configurable features are selected based on plexity observed by the build system user. Our dy- specifications written in a (mostly ad hoc) configuration namic analysis of build systems did not reveal a language. Second, the deliverables are constructed in the common pattern in the studied projects, although we correct order by observing dependencies that are typically observe linear growth and other interesting trends in specified in a build system language such as make or ANT. build-time length and recursive depth dimensions. Build systems play a key role in software development This paper provides the following contributions: processes. Build systems simplify the lives of developers, who constantly need to re-build testable artifacts after com- • An empirical study of the evolution of ANT build pleting a code modification. Build systems also play a key systems for four small-to-large open source systems; role in team coordination. For example, the continuous in- • A definition of the Halstead suite of complexity metrics tegration development methodology involves automatically for the domain of build systems; executing project builds and publishing results via email or • Evidence of the high correlation between the evolution web sites to provide direct feedback to developers about of build systems and the source code. software quality [1]. Maintaining a fast and correct build The remainder of the paper is organized as follows. system is pivotal to the success of modern software projects. Section II introduces the ANT build language and associated Build systems require substantial maintenance effort. A terminology. Section III elaborates on the research questions first example of this is given by Kumfert et al., who find that that we address. Section IV discusses the methodology for on average, build systems induce a 12% overhead on devel- the case studies we conducted on four open source systems, opment effort [2]. Second, the Linux build engineers made while Section V presents the results. Section VI surveys integration of new code trivial to encourage contributions. related work. Finally, Section VII draws conclusions. build.xml sub/build.xml <project name="example" default="link"> <project name="example-sub" default="compile"> <property name="blddir" location="build" /> <target name="init"> <property name="classes" location="${blddir}/classes" /> <echo message="In sub/build.xml" /> init <property name="dist" location="${blddir}/dist" /> </target> <target name="init"> <target name="compile" depends="init"> <mkdir dir="${blddir}" /> <javac init <mkdir dir="${classes}" /> destdir="${classes}" <mkdir dir="${dist}" /> srcdir="." </target> includes="**/*.java" compile /> <target name="compile" depends="init"> </target> <javac </project> destdir="${classes}" srcdir="maindir" includes="**/*.java" /> compile build.xml sub/build.xml <ant antfile="sub/build.xml" (1) target="compile" (3) /> init </target> init <target name="link" depends="compile"> (2) <jar jarfile="${dist}/example.jar" compile link basedir="${classes}" /> References </target> (5) (4) Follows <target name="clean"> <delete dir="${blddir}" /> link compile </target> </project> Figure 1. Example ANT build.xml files (left, top-right) and the resulting build graph (bottom-right). The build graph has a depth of 2 (i.e., “compile” in build.xml references “init” in sub/build.xml) and a length of 5 (i.e., execute (1), (2), (3), (4), then (5)). II. BACKGROUND not exist yet, are older than its input files, or at least one We now provide an overview of build system concepts and dependent target has been rebuilt. the ANT build language, which is the focus of our study. B. ANT A. Build Systems Concepts We study the evolution of open source build systems im- A typical build system consists of two major layers [6]. plemented in the ANT build language. ANT, an acronym for The configuration layer allows a user or developer to select Another Neat Tool, was created by James Duncan Davidson code features, compilers, and third-party libraries to use in 1999. He was fed up with some of the inconsistencies in during the build process, while enforcing any constraints the make build language, which was and still is the de facto or conflicts between these configuration options. The con- standard among build system languages [9]. Although make figuration layer may automatically detect a default set of pioneered many build system concepts, there are some rather configuration options by examining the build environment, gruesome flaws in its design, such as the inherent platform but these default values can be overridden by the user. In dependence of commands inside the make build rules and this paper, we ignore the configuration layer and assume that the common recursive architecture found in many make the default set of configuration options will suffice. build systems. To resolve these flaws, ANT was designed The construction layer considers the configuration options to be small, extensible, and operating system independent. that were selected by the user and parses the build specifi- Still, many of the concepts introduced by make survive in cation files to determine the necessary build tasks and the ANT. An example ANT specification file and the resulting order in which they must be executed to produce the correct build graph are shown in Figure 1. output. Construction layer (a.k.a. build) specifications are An ANT build system is specified in a collection of XML typically expressed in a build system language. Among build files. <project> tags contain all of the code relating to system languages, popular choices include make [7] and a software project. <target> tags correspond to the build ANT [8]. targets we explained above. Such a <target> is responsible Build specification files consist of various build target for a sequence of related tasks such as “compile all source declarations. A build target represents an abstract build goal files” (“compile” target in Figure 1) or “collect all class (or collection of goals) such as “completing all compilation files in a jar archive” (“link” target in Figure 1). <task> commands”. A target typically has two key characteristics, tags represent specific system-level commands inside a build (1) a build rule that defines the set of commands that must <target>’s build rule. A task may “create a directory” be executed when the target is triggered, and (2) a list of (“mkdir” tasks in the “init” target of build.xml) or “run the dependent targets that determine whether the initial target compiler on the given set of source files” (“javac” task in should be triggered. Heuristics are used to speed up a build the “compile” target of either XML file). The <task> is the such that a target is only triggered if its output files do lowest level of granularity in an ANT build specification file. Table I The ANT build language comes stocked with a library STUDIED PROJECTS of common build <task>s. If a <task> implementation does not exist, ANT provides an Application Programmer ArgoUML Tomcat JBoss Eclipse UML Web App IDE Interface (API) for developing expansion tasks. The Task Domain Editor Container Server API, like the ANT parser itself, is implemented for the Java Source Size ≤ 176 ≤ 277 ≤ 731 ≤ 2; 900 SE platform.