A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

• flexible

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

• flexible

  • allow for a variety of build actions

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

• flexible

  • allow for a variety of build actions
  • on a variety of platforms

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

• flexible

  • allow for a variety of build actions
  • on a variety of platforms

• configurable

A build manager is a tool for scripting the automated steps required to produce a software artifact.

What Should a Build Manager Do?

A good build manager should be

• easy to use

• easy to set up for a given project

• efficient in performing the build

  • avoid redundant/unnecessary actions
  • detect and abort bad builds in progress

• incremental

  • allow focused/partial builds

• flexible

  • allow for a variety of build actions
  • on a variety of platforms

• configurable

  • permit the management of multiple artifact configurations

What Constitutes a Sub-project?

Example: The AlgAE project has sub-projects

sub-project	deliverable
algae-client-server	algae-4.1.jar
algae-cppserver	libalgaecpp.a
algae-referenceManual	referenceManual.pdf
demos/FordToppBST	FordToppBST.zip
demos/ReferenceManualJava	algae-jrefman.jar

Why divide a project into multiple sub-projects rather than into multiple smaller independent projects?

Why divide a project into multiple sub-projects rather than into multiple smaller independent projects?

• The entire project is stored in a single location/repository.

Why divide a project into multiple sub-projects rather than into multiple smaller independent projects?

• The entire project is stored in a single location/repository.

• The entire project can be built with a single command.

Why divide a project into multiple sub-projects rather than into multiple smaller independent projects?

• The entire project is stored in a single location/repository.

• The entire project can be built with a single command.

• The entire project can share certain configuration data.

Why divide a project into multiple sub-projects rather than into multiple smaller independent projects?

• The entire project is stored in a single location/repository.

• The entire project can be built with a single command.

• The entire project can share certain configuration data.
• Sub-projects may be more tightly coupled than would be desired of independent projects.

The src/ directory is split into separate directories for the "real’ code and for the test code.

src/
|  main/   # things that contribute directly to the deliverable
|  test/   # things used for testing but not delivered
target/

• If the project is supposed to produce a Java application or a Java library, the deliverable is usually packaged in a Jar.

• Server-side web applications are delivered in a War or an Ear.

• Source code is sometimes packaged in a Jar, but more often in a Zip. (Usually, though, when we talk about deliverables in this section, we’ree referring to “binary” deliverables.)

• Android apps are packaged in an APK.

The division of the source files into separate main/ and test/ makes it easier to eventually construct those deliverable archives because we won’t treat entire directories worth of stuff uniformly, rather than having to select desired materials on a file-by-file basis.

src/main/ is further subdivided:

src/
|  main/
|  |  java/      # Java source code, compiled into target/classes
|  |  resources/ # data files that will be included in the deliverable archive
|  |  data/      # data files required during build but not part of deliverable
|  test/
target/
|  classes/ # data and compiled code that are packed into the .jar deliverable
|  project.jar # the deliverable

(These directories can be omitted if they are empty.)

Java libraries and applications can read data from files within their own distribution archive with only slightly more difficulty than reading from an ordinary file. To do so, the Java code is written to search the Java CLASSPATH, the same path used to hunt for the compiled Java code.

They cannot, however, write to those data files. The data access is read-only.

The src/test/ directory is split in an analogous fashion:

src/
|  main/
|  |  java/
|  |  resources/
|  |  data/
|  test/
|  |  java/      # Java source code, compiled into target/test-classes
|  |  resources/ # data files, available during testing via CLASSPATH
|  |  data/      # test data
target/
|  classes/
|  test-classes/ # data and compiled code for unit testing
|  project.jar

Test resources are intended to be accessible during testing via the code already written for accessing main (deliverable) resources. One way to support this is to copy the src/test/resources contents into target/test-classes, so that the same CLASSPATH-based mechanisms to locate the compiled test code will also find the test resources.

A similar directory structure is employed for Android projects. The Gradle build manager, which we will cover later in this section, has made the Android structure its default for Java projects, making it a popular organization for non-Apache projects.

The most obvious difference is that the products of the build are stored in build instead of target.

src/     # anything supplied/edited by the programmers
build/  # initially empty, holds products of the compilation/build

The src/ directory is laid out identically to the Apache organization:

src/
|  main/
|  |  java/      # Java source code. After compilation, is part of the deliverable.
|  |  resources/ # Data files that will be included in the deliverable, accessible via CLASSPATH
|  |  data/      # Data files needed for the build, but not part of the deliverable.
|  test/
|  |  java/      # Java source code for testing, will not be part of the deliverable
|  |  resources/ # data files, available during testing via CLASSPATH
|  |  data/      # test data
build/

Example: see this structure in the Code Annotation project

2.1 make

make is a command/program that enacts builds according to a dependency graph expressed in a makefile.

2.2 makefiles

At its heart, a makefile is a collection of rules.

2.2.1 Rules

• A rule describes how to build a single file of the project.

  Each rule indicates

  • The target file to be constructed
  • The dependencies: the other files in this project from which the target is constructed.
  • The commands that must be executed to construct the target from its dependencies.

• Rules may appear in any order

  • Except that the first rule’s target is the default built by make when no explicit target is specified in the command line.

The Components of a Rule

Rule Examples

 

codeAnnotation.jar: code2HTML.class CppJavaScanner.class
        jar tvf codeAnnotation.jar code2HTML.class CppJavaScanner.class

CppJavaScanner.class: CppJavaScanner.java
        javac CppJavaScanner.java

code2HTML.class: code2HTML.java CppJavaScanner.java
        javac code2HTML.java

CppJavaScanner.java: code2html.flex
        java -cp JFlex.jar JFlex.Main code2html.flex

Pros & Cons

3.1 ant

• ant devised by James Davidson of Sun, contributed to Apache project (along with what would eventually become TomCat), released in 2000

• Quickly became a standard tool for Java projects

  • slower to move into other arenas

3.1.2 Targets

At its heart, a build file is a collection of targets.

Example of Targets

<project name="JavaBuild" default="deploy"> ➀
  <description>
    Example of a simple project build
  </description>

  <target name="compile" description="Compile src/.../*.java into bin/"> ➁
    <mkdir dir="bin" />                    ➂
    <javac srcdir="src" destdir="bin"
           debug="true" includeantruntime="false"/>
    <echo>compiled </echo>
  </target>

  <target name="unittest" depends="compile" unless="test.skip"> ➃
    <mkdir dir="test-reports" />
    <junit printsummary="on" haltonfailure="true" 
           fork="true" forkmode="perTest">
      <formatter type="plain" />
      <batchtest todir="test-reports">
        <fileset dir="bin">
          <include name="**/Test*.class" />
          <exclude name="**/Test*$*.class" />
        </fileset>
      </batchtest>
    </junit>
  </target>

  <target name="deploy" depends="unittest" description="Create project's Jar file">
    <jar destfile="myProject.jar">
      <fileset dir="bin"/>
    </jar>
  </target>
</project>

➀ The project has a name and default target

➁ A basic target. It is named “compile” and has a description (which may be picked up by some IDEs)

➂ This target has 3 tasks. It creates a directory, compiles Java source code, and prints a message when completed.

➃ This target illustrates both a dependency and a condition.

3.2 maven

Another Apache project, Maven came well after Ant had come to dominate the Java open source landscape.

• Initially seen as a competitor or replacement for Ant

• Maven addresses both

  • build management (as does Ant)
  • and some aspects of configuration management (which Ant does not)

Stated goals are

• Making the build process easy

• Providing a uniform build system

• Providing quality project information

• Providing guidelines for best practices development

• Allowing transparent migration to new features

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>edu.odu.cs</groupId>                  ➀
  <artifactId>codeAnnotation</artifactId>        ➁
  <packaging>jar</packaging>
  <version>1.0</version>
  <name>codeAnnotation</name>
  <url>https://www.cs.odu.edu/~zeil/cs795SD/s13/Directory/topics.html</url>
  <description>
    This is a tool used to parse code listings and to 
    generate syntax-highlighted C++/Java listings in both
    HTML and LaTeX.
  </description>

  <!-- site generation:
       mvn test
       mvn surefire-report:report
       mvn site
  -->


  <repositories>
  </repositories>


  <dependencies>                                 ➂
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
    	<groupId>de.jflex</groupId>
    	<artifactId>jflex</artifactId>
    	<version>1.4.3</version>
    </dependency>
  </dependencies>
  <build>
    <plugins>                                  ➃
      <plugin>
        <groupId>de.jflex</groupId>
        <artifactId>maven-jflex-plugin</artifactId>
        <version>1.4.3</version>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins> 
  </pluginManagement>
  </build>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>
</project>

• ➀ identifies the organization that produces this project
• ➁ identifies the project
• ➂ identifies 3rd party libraries required by the project
• ➃ plugins modify the normal Java build action

3.2.3 Observations

• POM files are ugly as sin.
• Although technically task-based, tasks are supplied by archetypes.
  • Idea is to enforce “best practices”
• If you need an unusual task in your build
  • if there’s a plugin already written, you’re golden
    • e.g., the jflex plugin at ➃
  • if not, you’re up a creek.
    • Custom tasks within a build file are all but impossible.
    • In fact, one of the most commonly used plugins is one to “invoke ant and ask it to take care of this”

3.3.1 Dependencies

• pom.xml files have a dependencies section. e.g.,

    <dependencies>
  	<groupId>junit</groupId>
  	<artifactId>junit</artifactId>
  	<version>4.10</version>
  	<scope>test</scope>
    </dependencies>
  
  

• This indicates that our project requires the junit package.

• Could also say [4.10,] to get versions 4.10 or greater

• By default, Maven searches the ibiblio repository, which can be human-searched here.

• Try searching for junit

  • Notice range of versions available
    • Select one (e.g., 4.10)
  • The “Maven” tab shows what to put into your <dependencies> section to request this version.