Initial outline for the entry for http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1
Here is the Input submitted for July 2003, Use this same page when the Aug starts.
Gump has accumulated 168 modules, providing 380 projects, and continuous integration builds are running nightly on at least five public servers. Of these modules, 20 have delegated their descriptors to project CVS repositories, which allows local management of this. Gump extracts source code from over 24 CVS repositories, with most CVS repositories hosting multiple modules. Recent additions were new modules for jUDDI (http://cvs.apache.org/builds/gump/latest/juddi.html) and Jakarta POI version 3 (http://cvs.apache.org/builds/gump/latest/jakarta-poi-3.html).
In order to improve the process around Gump, it has been added to Bugzilla. Users can submit bug reports and/or requests for change in an organized process.
Gump has suffered some outages, primarily due to: hardware failures (lightening damage), CVS locks on remote CVS servers (hanging CVS updates), and CVS outages in remote servers. Also, with the length of a gump run now exceeds 7 hours, which can leads to build starting generation on one day and ending on another (exposing a @
Although "SUCCESS" builds are the norm, there are numerous "PREREQ FAILURE" when builds are marked as "FAILED". This represents healthy project sharing/re-use/cooperation, which is exactly what Gump to promotes and facilitates. The nightly gump output (see: http://cvs.apache.org/builds/gump/latest) reads like a dashboard on the state of "Open Source Sharing".
Gump is starting to see more use as "personal" Gumps, where the modules/projects that are not all available for public CVS access can benefit from continuous integration, Additionally, some installations are for a "trimmed stack" for build speed/focus.
As a corollary, gump is seeing more use with "packages" (pre-installed base software) – reducing build time, and focusing the builds on specific software. Nick Chalko contributed the ability for gump to convert module definitions to "nobuild" equivalents, on the fly. These descriptors contain the <jar information (for CLASSPATH dependencies) but no <ant/<cvs/<script directives. As such, they convey the jar metadata without invoking a build. This allows for package-based builds of the original metadata, removing manual editing.
Further, a *nix gump.sh script is evolving to allow a standard build process (combining the various gump build steps) to make it easier for users to install/run their own gumps.
Work in this area is ongoing.