Getting started with WildFly Builder
Stamp a Java EE / WildFly app from options, template, and an extender.
WildFly Builder stamps a Java EE application from three things: a shared template, an options / metadata file, and an app-specific extender. This page is the short path from an empty directory to a running WildFly app.
If you only want the idea, read What is a software factory? first. If you want the phone-side twin, see Getting started with Droid Builder.
What you need
A JDK that can run the version of WildFly you deploy to.
Git.
Maven or the wrapper that ships in the generated app.
A local WildFly (or the container setup the app repo documents).
The WildFly Builder source. The builder page on this site links the Git repository: https://sw-builder.com/appstore/builders/apps/wildfly-builder.html
The mental model
template/ is the chassis: project layout, persistence, security hooks, the pages every app in the line gets.
build/ (and the XML fragment lists) is the parts bin.
The options file names entities and fields.
The extender — BookletExtender, SocialExtender, and so on — chooses fragments and writes them onto the chassis.
Build scripts live in the generated app repo, not inside the builder. A typical script pulls WildFly Builder, overlays template/ and the snippet library, runs the generator plus the extender, then you build the war the way you would any Java EE app.
Stamp a first app
Start from a known product in the catalog so you are not inventing options on day one. Booklet is the live demo on this domain.
1. Clone the Booklet app repo (or another WildFly catalog app) and the WildFly Builder repo side by side.
2. Read the options / metadata in the app repo. That file is the contract. Entities, field types, names.
3. Run the app’s build script, the one that pulls the builder, overlays template/ and snippets, and invokes the extender.
4. Build the war.
5. Deploy to local WildFly.
6. Open the app. For Booklet on this site that is https://sw-builder.com/booklet/do?op=Home with guest / guest.
If the script fails, stay in the generated repo. The factory already did its job when the sources appeared. From here it is a normal Maven / WildFly problem: missing datasource, wrong Java version, port in use.
What “done” looks like
You have a war you can deploy.
The domain tables match the options file.
The screens the extender promised are present: for Booklet, books, pages, and the read / browse flow.
You can change an option, run the factory again, and see the chassis stay put while the optional parts move.
Make a second product line member
Copy an existing catalog app. Change the options: rename entities, add a field, drop a screen the extender does not need. Run the same overlay. That is how Social and Security sit next to Booklet without becoming hand-built one-offs.
Do not start by rewriting the template. The template is the factory floor. If every app edits the chassis, you no longer have a line.
Where the rest of the notes live
Per-app setup still lives next to that app’s source and wiki. This page is the shared path so the site itself can explain the factory without sending a reviewer only to GitHub.
Catalog: https://sw-builder.com/appstore/wildfly/
Builder: https://sw-builder.com/appstore/builders/apps/wildfly-builder.html