Notes about properties files

The DDMS stores its properties files in what is called profiles. These profiles are designed to allow to user to configure the DDMS differently for different environments. These profiles can extend eachother, leading to very complex configuration chains. When the DDMS is built/deployed, the profile is flattened and the production properties files are built and merged into a single properties file. In practice, this mechanism has proven itself to be a little over-engineered and serves to hinder development more than it helps. That being said, here's how the properties are built for a build:

1. The build system starts with the properties from either installer or patch to configure itself when building the database. It then replaces a lot of these properties using settings hardcoded in the installer.xml or patcher.xml ant build script.
2. After the production database is built, the installer/patcher ant build system kicks off an ant build in the DDMS build.xml. This DDMS deploy build is configured with a profile (typically either install or patch). The profile it uses is hardcoded in either installer.xml or patcher.xml.
3. The DDMS build looks at deploy.properties and reads the deploy.profile setting.
4. This deploy.profile setting is sent into the ProfileFlattener which does the dirty work of flattening the properties files with all their super and import references resolved and compiled into a standard Java properties file.

As a result of this complexity, the actual production properties are a merged amalgam of the default, deploy, installerdeploy, and patchdeploy. For this reason, be extremely careful when changing any properties files! It's very possible you could corrupt production with a very simple change.