Apache Gump
# Apache Gump

Apache Gump is an open source continuous integration system, which aims to build and test all the open source Java projects, every night. Its aim is to make sure that all the projects are compatible, at both the API level and in terms of functionality matching specifications. It is hosted at gump.apache.org, and runs every night on the official Sun JVM.

## History

Gump was created by Sam Ruby, based on his experience in the Perl community. It was originally written in Java.

The current live version, Gump 3, has been completely rewritten in Python.

## Usage

To join Gump, a project must provide two XML files. One describes how to access the live CVS or Subversion repository; the other what to build from the repository, and the artifacts produced. Each project can be dependent upon other projects; these dependencies are declared so that Gump knows the correct order to build things.

Gump can build shell script, Ant and Maven 1 projects, setting up the classpath appropriately. Ant and Maven 1 have special hooks built in them to give Gump complete control of the classpaths used to build and test the applications. This allows Gump to build the projects against the latest versions, even if the project's own build files have hard coded dependencies against static libraries in their own CVS or subversion repository.

If a build on Gump is successful, a report is placed on the site, and all projects that declare themselves dependencies are eligible to be built. If a project fails to build, error reports are published, an error email is sent, and all dependent projects are blocked from building.

## Limitations

* There is no way to force developers to act on the you broke the build email, other than informal peer pressure.
* Until Maven support is added, many Java projects cannot be built. All projects downstream of these can only build on gump with static versions of the previous releases, removing the possibility to build and test against nightly code, one of the key features of the project.
* It can be difficult to diagnose why something has failed, as developers on projects built by gump do not have access to the machine, only the nightly status reports.
* As it is an open service for all open source projects, the project has invested less effort in making it easy to bring up a new gump installation, which makes private use harder. In particular, there is no automated way to provision a gump server with the static JAR files that many projects depend upon.
* If a foundational project such as Ant, Xerces or JUnit fails to build, then most of Gump is blocked until a fix is made. Depending on the nature of the failure, this could be a quick procedure, or could take longer.
