Apache Gump
Developer(s) | Apache Software Foundation |
---|---|
Written in | Python |
Operating system | Cross-platform |
Type | Continuous integration |
License | Apache License 2.0 |
Website | http://gump.apache.org |
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.
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, then 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.
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.
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, there is a large swathe of Java projects that cannot be built. All projects downstream of these are only able to build on gump with static versions of the previous releases, removing one of the key features of the project: to build and test against nightly code.
- Diagnosing why something has failed can be hard, because developers on projects built by gump do not have access to the machine, only the nightly status reports.
- Because 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. This makes private use harder. Of particular note, there is no automated way to provision a gump server with all 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 can be a quick fix, or it could take longer.[1]
References
External links
|