BedeWork Documentation

September 17th 2005

The Quickstart

A working version of the calendar is provided as a downloadable quickstart file. This includes a version of tomcat, hsql and ant as well as all source and jar files required to build and run a basic version of the calendar system.

You should familiarize yourself with the various components before attempting to build a production version of the calendar for your site.

Updating the quickstart

If you need an up to date version of the calendar source it can be downloaded from the CVS repository at the web site. You can either update or replace the calendar3 component of the quickstart. Having done so you should execute the quickstart.build target in the calendar3/build.xml file which will copy updated files out of the calendar3 component into the quickstart.

Building

Currently the bedework quickstart build uses jakarta ant 1.6. You will need to download and install this version (or later) before building.

Defining local properties

You should be able to make local configuration changes by adding properties to

<user-home>/bedework.build.properties

The values in this file will override those defined in the distributed build. The properties and some example values are:

#where the application server lives

appserver.dir=${calendar.dir}/../jakarta-tomcat-5.0.28

#where the default db is

hsqldb.dir=${calendar.dir}/../hsqldb_v1.7.3

#Additional location for generated jar files

#.e.g. maven repository

org.bedework.jars.repository=/home/douglm/.maven/repository/bedework/jars

#servlet version to build for

org.bedework.servletapi.version=2.4

The first two allow you to use other than the distributed servlet container and database system. Specifying an additional repository for jar files allows builds to autopmatically update that repository with new versions.

Specifying the servlet version allows the build to produce versions of the web applications for different api specifications.

Overview of the Database

Users

Every user of the system, whether administrator or private user, must have a user entry in the database. Database constraints require this and much code depends upon it.

Administrative Groups

These are the owners of public events. A group id should not be the same as any valid user id. There is a configurable administrative group prefix which is designed to ensure this is the case. If a site intends having all public events visible to all administrators then create one group and assign all administrators to that group.

Administrative groups allow departments to nominate a number of people to enter and update public events. Absences then do not require the intervention of some central authority.

Timezones

To process timezones the system needs to be loaded with an appropriate set of timezone definitions. We have chosen to use data created by the vciz program which processes the Olson timezone database files into VTIMEZONE files.

Download the vciz program and unpack it. The README will provide he location of Olson database files and some build instructions. The build property TZID_PREFIX should be set to the null string. This will result in timezone ids of the form “Europe/London”.

The result of running vciz will be a directory containing directories and ics files. Log into the calendar admin application as a super user. Click on the menu item for reloading system timezones and browse to the directory generated by the vciz program.

Clicking the upload button should result in a fresh set of timezones being uploaded. This process will need to be repeated each time the timezone definitions change.

Building a non-quickstart version

A lot of the configuration of the final result is determined by the properties file(s) in config/configs. The quickstart comes with a single file democal.properties. As a start, you should copy this to another file, call it prodcal.properties.

Next, create a properties file bedework.build.properties in your home directory. In this file you need at least the following property:

org.bedework.clone.default=prodcal

This will override the property in the build process and use your prodcal.properties file to configure the final applications.

A further property is by default:

<property name="org.bedework.defjars"

location="${bld.home}/defjars.properties" />

Overriding this allows you to redefine the library jar files used during the build.

2004-12-28T10:03:51