A JDK that redefines classes while the application runs, Eclipse with Parslips, and Maven pointed at the WOCommunity repository. The JetBrains Runtime through SDKMAN!, HotswapAgent in one copy, and the VM arguments that make it all work.
From the first route to groups and filters: declaring routes, parameters converted to your objects, links built from the routes so they can't go stale, handlers, forms, and the same URLs on localhost and in production.
The configuration composed from every source before the application is constructed, where each value came from, reading and watching properties, and plugins: frameworks that take part in startup at three named points, and moving over from ERXFrameworkPrincipal.
reload4j or logback behind slf4j, levels and a layout set with properties every backend understands, the backend's own configuration on top, levels changed on a running instance, and existing log4j configuration that keeps working.
Pushing from the server to the browser with wo-adaptor-jetty: server-sent events that stream over an ordinary HTTP response, broadcasting to every connected client, WebSockets when the browser needs to talk back, and the client-side traps worth knowing before you start.
From an empty directory to a self-contained .woa: the pom, the project layout, build.properties, the bundle and its launch script, frameworks, deploying to JavaMonitor, and migrating from wolifecycle.
One Maven command ships a build: the bundle is posted to JavaMonitor, and wotaskd swaps it into place and restarts the instances on every host. Configuration, use from a build server, what happens on each host, rollback.
What belongs in a project's build.properties today: the handful of current keys, what each means and which tool reads it, and every legacy key from WOLips, wolifecycle and Wonder's builds, with what replaced it.
modulo alone on ports 80 and 443: TLS from Let's Encrypt via native ACME, virtual hosts, static files and routing to instances, from one TOML file. No Apache, no certbot, no compiled module. The field-tested path, and the one we run ourselves.
Apache keeps the edge — certbot certificates, vhosts, static files — and modulo stands behind it as the WO-aware reverse proxy, replacing mod_WebObjects without compiling anything. For an Apache estate you can't, or won't, retire.
Deployment as it has been done since the last century: Apache with a compiled mod_WebObjects module, certbot, and a C toolchain on the production server to build it. Published for comparison, so you can see what the other two leave out.
Each guide is a single shell script, shown in full with an explanation beside every step. You run it from your workstation against a fresh Linux server you have root ssh access to, and a few minutes later the server is serving over a real certificate, ready for apps.
The three scripts share most of their length. All of them build wotaskd and JavaMonitor locally with Maven, install a JDK on the server if one is missing, lay out /opt/webobjects, create an unprivileged webobjects user that everything runs as, install systemd units and log rotation, and start the stack. Every one of them ends the same way: wotaskd launching and watching instances, JavaMonitor as the place you add apps, certificates from Let's Encrypt.
Where they differ is the edge: what listens on ports 80 and 443, and how a request finds its way from there to an application instance. That choice is the whole difference between the three, and it's what each guide is named after.