Build

KFS uses Ant for deployments and unit testing.

Build Properties

Configuration properties may be specified by certain files which are looked for automatically by the script. The first definition of a property will be used by the build, i.e. Ant does not work like many other things where the last value wins. There are three locations that that the build script attempts to load properties from, in the order specified:

1. ${user.home}/kfs-build.properties

   User Home Locations

   • Unix: /home/username/kfs-build.properties
   • Mac OS X: /Users/username/kfs-build.properties
   • Windows XP: C:/Documents and Settings/username/kfs-build.properties
   • Windows Vista, Windows 7: C:/Users/username/kfs-build.properties
2. ${institution.build.properties.file} (location set in the above kfs-build.properties)
3. ${build.environment}-build.properties
4. The build/propertiesdirectory in the kfs project. You should not generally change the properties here. Override them in one of the above files.
   • build/properties/build.properties
   • build/properties/build-foundation.properties
   • build/properties/database.properties
   • build/properties/directory.properties
   • build/properties/logging.properties
   • build/properties/batch.properties
   • build/properties/email.properties
   • build/properties/url.properties
   • build/properties/rice.properties
   • build/properties/spring.properties
   • build/properties/web.properties
   • build/properties/b2b.properties

For ease of future upgrades, you should avoid modifying any of the delivered files under the kfs directory. Instead, you can override any or all of those properties in the first two. For example...

1. Create a second build properties file in the root of the project (e.g. sampleu-build.properties).

2. Ensure that your new properties file will be loaded by adding the following to your ${user.home}/kfs-build.properties file.

   example institution properties reference

   institution.build.properties.file=sampleu-build.properties
   

Build Target Overview

To deploy a KFS distribution, you can use the dist or dist-local targets of the KFS build.xml. To execute the KFS unit tests, you can use the test-local or continuous-integration targets.  The continuous-integration target is intended for use within an automated testing tool like Jenkins. See the setup instructions and the help target in the build file itself for more information.

Directory & File Creation

KFS requires that certain external directories and files exist at runtime.

• The settings and security directories must be created and populated

  The goal of externalizing some of the application configuration is to allow for modification without a deployment. Also, the secure information contained in some of these files (e.g. database passwords) has different access requirements than code does.

• The logs and work (attachments, reports, staging) directories must be created
• Certain files must be added to the application server

The dist-local target accounts for these external dependencies. It copies the files and folders in the build/external directory of the project to their expected locations. The expected locations are configurable via build properties. The configuration properties page lists the default values for the properties that control the expected locations.

The copies will only me made if the is.local.build property is set. When not set, the build process assumes you are building a WAR file for an already configured server. So, you will want to review the dist-local target for what gets copied. Review the table below for most of the files which are being copied.

The dist-external target will generate three files containing external dependencies that can be unpacked on a server:

The dist-local and dist targets both generate / extract certain files that reside within the application itself, using the contents of the build/project directory.