Building Metacat | Back | Home | Next

Table of Contents
About Building Metacat

This documentation covers building Metacat on a local development environment. In essence, the local development build is no different than the production build, but a few convenience options have been added to help the developer.

These instructions are meant to augment the Install Metacat War section of the following guides

- Metacat Linux Installation Guide.
- Metacat Windows Installation Guide.

Metacat is built using the Ant build utility. You will need to have Ant installed on your development system to build Metacat

Prep the Build Configuration
build.properties

You will need to edit /build.properties and make sure the following values are correct:

- build.tomcat.dir - Metacat will look for some HttpServlet libraries in the local Tomcat directories. Make sure this value is set to your local Tomcat installation directory.
- app.deploy.dir - the automated installation build (install) will deploy your war file for you and clean up old application directories. Make sure this is set to the directory where Tomcat looks for its applications.
- cvsroot - if your cvs user is different than the user you are using to build metacat, you will need to change
  :ext:${env.USER}@cvs.ecoinformatics.org:/cvs
  to
  :ext:<your_cvs_user>@cvs.ecoinformatics.org:/cvs
  If you do not have a personal account with cvs, you can set the username to "anonymous". The password will be "guestaccess".

build.xml

There are several adjustments you can make to the build by editing >metacat_workspace</build.xml. Some of the common ones are:

- eml2_1_0-schema-tag - the tag in the eml repository that Metacat will use to check out EML schema code. You would change this if you want to check out the latest code on the head (leave as "") or if you want to run against an older version.
- eml2_1_0-style-tag - the tag in the eml repository that Metacat will use to check out EML style code. You would change this if you want to check out the latest code on the head (leave as "") or if you want to run against an older version.
- util-module - this tells metacat where to checkout to and/or look for the common utilities code. Typically this is in a directory named utilities at the same level as Metacat code. You could change this to point to an alternative directory which may have different utilities code (from a different branch for instance).
- utilities-tag - the tag in the utility repository that Metacat will use to check out utility code. You would change this if you want to check out the latest code on the head (leave as "") or if you want to run against an older version.

Cleaning the Codebase

The metacat build.xml has several methods for cleaning the codebase. The format for running these is:

ant <clean-target>
The available clean-targets are:

- clean - removes build and dist dirs. This will cause a rebuild of code in the metacat project.
- localclean - does a clean plus removes utilities and httpclient jars. This causes a rebuild of utilities and the metacat project. This is provided so the developer does not need to download all eml files every time utilities change.
- ant fullclean - do a localclean plus remove eml files, so the system will checkout eml files from the eml module in CVS.

Automated Build

The ant "install" target controls deploying Metacat locally. This can be used for source distributions or code that was checked out of the repository. What is does is:

- Builds the Metacat project, resulting in a war file.
- Moves the war file to the app.deploy.dir that you set in build.properties
- Removes the existing application directory from the app.deploy.dir.

Typical usage would be something like:
ant fullclean install
Manual Build

You can also build the Metacat war file and deploy manually. To build and create the war, run:

ant build-metacat

The war file will appear in your >metacat_workspace</dist directory. Copy the war file into your tomcat webapps directory. Delete the existing code that was expanded from the old jar.

Back | Home | Next