Override default properties in cal.properties
Inside the bwbuild/.defaults directory, next to your configuration directory, you'll find a file named bwbuild/.defaults/cal.properties. cal.properties is referenced during the Bedework build and during deployment. You can override any of those properties by creating a bwbuild/myconfig/cal.properties in your configuration directory and editing in the overrides. cal.properties is divided into sections with different property prefixes.
...
Under Install Options, prune the org.bedework.install property
...
org.bedework.install defines which applications are built and deployed to jboss. For each name on the list, there should be a corresponding section prefixed with “org.bedework.app.<name>” and also a corresponding section in the options file.
Remove any items from Copy org.bedework.install to your override file, and remove any applications that you don't need. For example, if you're using Bedework for public events (and not for personal calendars), you can remove UserCal from the list. You may probably want to remove " test and SoEDept", too; it's an example. When you remove an application from the list, you can also remove the corresponding stanza further down the file, but it isn't necessary. Those lines won't be referenced.
Review the Global Section of the file
The section prefixed “org.bedework.global” defines properties global to the whole deployment process. This is the section where jboss's datasource (database) is defined. If you based your configuration on the sample configuration that corresponds to your database system, then you may not have to alter any settings in this section. The values set in this section work for most sites.
Review the Application Section of the file
The section with properties prefixed “org.bedework.app.<name>” are the application deployment properties, one section per named application.
Two properties define the project and type of application. The value of the property “org.bedework.app.<name>.project” defines which project the application is a part of. Currently these can be
- “caldav” - a caldav server
- “caldavTest” - a caldav test package
- “webapps” - a web client
- “dumprestore” - a dump/restore application
- “freebusy” - the freebusy aggregator
The value of the property “org.bedework.app.<name>.type” corresponds to the name of a subdirectory in bedework/deployment, e.g. webpublic, webadmin, etc. So to define the administrative client named CalAdmin of type webadmin we have the fragments:
org.bedework.install.app.names=...,CalAdmin,...
...
org.bedework.app.CalAdmin.project=webapps
org.bedework.app.CalAdmin.type=webadmin
This is where the per-application properties are set. The values set in these in this section also work for most sites.
Multiple versions of each application type may be deployed, each configured differently. This is of importance for calendar suites (departmental calendars).
...
You can see how this works by comparing the stanza for the "Demo departmental public Web Client" to the stanza for the "Public Web Client".
Set the run time properties in cal.options.xml
bwbuild/myconfig/cal.options.xml contains run time properties and is divided into sections much like the cal.properties file. Most of the options are used to set field values in named classes so that the application will load the settings only once with a single call.
It is important to set the “system” properties for a new Bedework installation. These are found in the “syspars” section of the cal.options.xml file. A number of Most options can be left with the default values and some are not yet implemented. The three values it is particularly important to set (and their default settings) are:
Set the default timezone: tzid property
Look for:
| Code Block |
|---|
<tzid>America/New_York</tzid> |
The tzid is the default timezone to be used for times and dates.
Set the system ID: the systemid property
Look for:
| Code Block |
|---|
<systemid>demobedework@cal.mysite.edu</systemid> |
systemid is used when generating uids for calendar entities. This name should relate to your organization for ease of identification. If you run multiple Bedework systems, use a different value for each. In addition, the systemid takes part in the creation and interpretation of calendar user addresses which appear in attendees. The part following “@” will probably be the domain to which imip messages are addressed (in some as yet undefined manner).
For example, your systemid might be "bedework@myorganization.com" or "bedework@myuniversity.edu".
Calendar user addresses take the form of a “mailto:” uri so that user “testuser01” on a system configured as above would have a calendar user address of
...