These are a few notes in case you need to work on GUMS

GUMS build requirements

GUMS uses Maven as the build system, you'll need to install version 1.0.2 as this is what we are using. The build should work with Maven 1.1.x, but it won't work with Maven 2.x, as it is not compatible with Maven 1.x. Make sure you edit your to setup the web proxy, if you need to.

Access to the CVS repository

Currently, access to the repository is restricted, and you need to request access by sending an e-mail to

Checking out the project

You can use CVS to checkout the project:

[gums@griddev01 gums]$ mkdir cvs
[gums@griddev01 gums]$ cd cvs
[gums@griddev01 cvs]$ export
[gums@griddev01 cvs]$ cvs login
Logging in to
CVS password:
[gums@griddev01 cvs]$ cvs co -P siteAAA/GUMS
cvs checkout: Updating siteAAA/GUMS
cvs checkout: Updating siteAAA/GUMS/components
U siteAAA/GUMS/.cvsignore
[gums@griddev01 cvs]$ cd siteAAA/GUMS/


GUMS is composed of multiple project: a top project, and the subprojects: business logic, client, service, and privilege (the OSG AuthZ stubs). The subprojects are located in the ./components/* directories. Maven knows the dependencies between those, and with a single command can build everything.

[gums@griddev01 GUMS]$ maven multiproject:install-snapshot
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2


[echo] Gathering project list
Starting the reactor...
Our processing order:
Privilege Project
GUMS Client
GUMS Service
| Gathering project list GUMS bl
| Memory: 4M/5M
| Gathering project list Privilege Project
| Memory: 4M/5M
| Gathering project list GUMS Client
| Memory: 4M/5M
| Gathering project list GUMS Service
| Memory: 4M/5M
Starting the reactor...
Our processing order:

Configuring the Unit tests

The build will break: the Unit tests will need an LDAP server and a database server properly configured to succeed. And if the tests do not succeed the build breaks. If you do not have those services available, you can skip the tests by editing the ./siteAAA/GUMS/ Look for the skip test property and uncomment it.

If you want to run the tests, you can either set to skip those tests that do require the external servers (by editing the ./siteAAA/GUMS/components/business/project.xml, look for the test excludes sections) or you will need to create the following confiugration files in ./siteAAA/GUMS/components/business/src/conf:

  • a file: these are the same properties you would use to configure the HibernatePersistanceFactory: you can look at the GUMS configuration documentation. For more details, refer to the Hibernate configuration documentation.
  • an file: these are the same properties you would use to configure the LDAPPersistanceFactory. For more details, you can also look at the JNDI documentation for creating an LDAP Context
  • a file: these are the same properties you would use to configure the MySQLPersistanceFactory. You can also refer to the mysql driver parameters.

The VOMS tests will also require a pair of host certificate/key in your home directory (~/etc/grid-security/hostcert.pem and ~/etc/grid-security/hostkey.pem)

Nightly build

GUMS is build every night at 1:00 AM on griddev01. In /home/gums you'll see a script: that's what is run every night and gums.out is the output. The script will simply run some maven goals to:

  • Clean
  • Updated from CVS
  • Build all the pieces of GUMS (and GT4 PRIMA)
  • Place all the pieces on the web server in the maven repository (
  • Build the GUMS site
  • Install the new GUMS snapshot on the test server

If the build is broken for whatever reason, the site won't be generated. So, if you see on the GUMS web pages that the site is older than a day, the build process is broken. This is a good check as it guards for typical mistakes, such as forgetting to commit all changes in CVS.

The configuration is also in CVS, so be aware that if you modify the configuration file on the test server, it will be replaced.

The same directories used by the nightly build, and the same tasks, can be used during testing to refresh the test server, rebuild packages and redeploy them in the maven repository, regenerate the web site, etc...

Tars and rpms

Maven by itself does not build tars and rpms. But it has a general way of handling "artifacts" (the output of the build process). In a few projects, you'll find goals such as tar:tar, tar:install, tar:install-snapshot, etc... Those are all conventions (jars and wars follow the same convetions) within Maven 1.0.2 that allows it to create a tar and place it on the maven repository in the web server. Those goals are build so that the multiproject goal of the top project will know what to build.