Almost every WebObjects project has a build.properties at its root, and most have collected keys over the years from tools that have come and gone. This guide describes what the file is for today: the keys a modern project uses, what each means and which tool reads it, and, separately, every legacy key you're likely to find, with what replaced it.

"Modern" here means a project built with vermilingua, edited with Parslips, and, for WebObjects applications, running on wonder-slim. It describes wonder-slim 8.0.12, vermilingua 1.1.10 and the current Parslips.

1. What belongs in it

build.properties holds facts about the project that tools need without running it: what the project is called, whether it's an application or a framework, which class starts it, how its templates are written, and how the built application is launched and deployed. The build reads it, the editor reads it, and so does the framework when an application runs from its project folder.

Configuration of the running application, the port, the database, logging levels, belongs in the application's Properties. A rule of thumb: if a deployed application should be able to change it without being rebuilt, it isn't a build.properties key.

It's a plain Java properties file, one key=value per line, next to pom.xml. These read it, each for its own keys, ignoring the rest:

ng-objects applications don't read the file at runtime; for them it's the build and the editor that do. Older readers, WOLips and its Ant builds, and the wolifecycle Maven plugin, account for most of the legacy keys.

A build.properties with keys like bin.includes, source.. and output.. belongs to an Eclipse plugin project, which uses the same name for an unrelated file. Nothing here applies to it.

2. The modern file

This is a complete build.properties for an application, every current key included. Only the first four are required; the rest are there when the project needs them.

# What the project is (required)
project.base=wo
project.name=MyApp
project.type=application
principalClass=com.example.Application

# How its templates write bindings (only when not the defaults)
component.inlineBindingPrefix=$
component.inlineBindingSuffix=
component.wellFormedTemplateRequired=true

# How the built application's launch script starts the JVM
launch.jvm=/opt/jdk-25/bin/java
launch.jvmOptions=-Xmx2g

# Where vermilingua:deploy ships it
deploy.monitorHost=https://javamonitor.example.com
deploy.appName=MyApp

Most projects need only this:

project.base=wo
project.name=MyApp
project.type=application
principalClass=com.example.Application

A framework has no main class, so three lines:

project.base=wo
project.name=MyFramework
project.type=framework

That's what Parslips writes when it creates a project.

3. The current keys

What the project is

How templates write bindings

For the editor: Parslips reads these to parse and validate the project's templates. They change nothing at runtime, and a key set to its default can be left out.

Launching: launch.*

vermilingua writes these into the built bundle's config.txt, and its launch script reads them to start the JVM.

Deploying: deploy.*

Read by vermilingua:deploy, which ships a build to JavaMonitor; the deployment guide covers it in full.

Per environment and on the command line

The launch.* and deploy.* keys can be set at three levels when building, a later one winning:

1. build.properties,
2. build.properties.<env>, when building with -Dbuild.env=<env>: a file holding only what differs in that environment, say build.properties.prod,
3. a system property, as in mvn package -Dlaunch.jvm=….

And a built application can still be started with different ones: ./MyApp -launch.jvm=… overrides what the bundle was built with.

4. When the file's presence matters

wonder-slim takes a build.properties in the directory an application starts in as the sign that it's running from its project folder, in development, rather than from a built bundle. It turns on development mode, which among other things shows source code on the exception page, and has NSBundle load the application, and the framework projects open alongside it, from their project folders. The console says which it found:

== build.properties found. Setting development mode. Setting NSProjectBundleEnabled=true ==

A built .woa contains no build.properties, and its launch script starts the application inside the bundle, so a deployed application runs in production mode without any configuration.

5. Legacy keys

Everything else comes from WOLips' Ant builds, the wolifecycle Maven plugin, or Project Wonder's own build scripts. WOLips writes most of these into every project it creates, which is why they're everywhere. Nothing in a modern project reads them, and each can be removed, or, where it has one, replaced by its current equivalent.

ERFoundation also reads a woantbuild.properties in place of build.properties when a project has one, a leftover from older Ant setups. A project that has both should keep only build.properties.

6. Bringing a project up to date

1. Make sure the four required keys are there: project.base, project.name, project.type and, for an application, principalClass.
2. Rename jvm and jvmOptions to launch.jvm and launch.jvmOptions, and drop jdb and jdbOptions.
3. Remove the component.* keys that are set to their defaults.
4. Remove every legacy key, keeping classes.dir only if the project is still built with WOLips.
5. Build with vermilingua and launch from Eclipse once, and check that the bundle is named as before.

The result is usually four lines where there were fifteen.