Email System Configuration Management

This document outlines the various components (configuration items) included in the Email message answering service, their relationships, unique identification and revision control.

List of Configuration Items

The following list indicates what software components are shipped with the system and how each relates to the others.

Shipped Items

  • email_application_1_0.zip - enclosing jar

    • Top Level Components

    Within the email_application_1_0.zip are the following items:
  • email.ear - application
  • email.rar - email connector
  • src.jar - source code
  • doc.jar - documentation

    • Secondary Level Components

    These items are contained within the email.ear (jar file) and constitute the actual application:
  • email_utilities.jar - common utilities
  • dispatch.jar - dispatching message bean
  • responder.jar - responding message bean
  • dictionary.jar - word lookup message bean
  • phone.jar - phone number lookup message bean
  • stock.jar - stock quote message bean
  • weather.jar - weather report message bean
  • web.jar - web page fetch message bean

    • Relationships

    There is some duplication of utility classes. This is required in order to make the individual jars correct components. For example, email.rar also includes email_utilities.jar because it relies on those classes, and without it would not pass validation.

    The worst offender is the WebBean class which is included in each of the slave robot jars that access web pages (stock, weather and web) since they are subclassses and must include it to be fully formed message beans (it's unclear how to resolve this, or even if it can be resolved).

    Levenshtein string distances are used by both the phone and word message beans.

    Identification

    The jar files all have manifest entries that allow for the programatic query of version information according to the Package Version Identification specification. Specifically, the version information available from java.lang.Package.getImplementationVersion() is composed of a major, minor and build number. The build number is a concatenation of year, month, day, hour, minute and second of when the build process was started. For example, 1.0.20021126203913 indicates version 1.0 built at 8:39:13 November 26, 2002. This is handled automatically by the Ant build script.

    Revision Control

    The source code is under revision control using CVS. Source files can be labeled internally with the CVS version number but that's in the future when a smart version diff doesn't show these as differences.