Software Builder Factories

Like a car factory for software

When you buy a car, you do not design it from scratch. You pick a make, a model, and a color — a short list of options. The factory does the engineering and stamps a standard product with a repeatable process.

Droid Builder and WildFly Builder work the same way: one product line, a few option files, a complete application. The factories are narrow on purpose, so the process stays repeatable. After the stamp, the result is a normal Android or WildFly project that you own.

Typical generators are tied to one platform. An Android Studio template emits an Android project. A Spring wizard emits a Spring project. You cannot take that same options file and stamp a matching product on another platform.

An LLM is even looser. It writes a first draft of a repo. After that you are on your own: the prompt is not a contract, the next run will not match the last one, and there is no shared chassis to stamp again.

What this site is for

• Show how to stand up your own WildFly server.
• Create lots of useful apps.
• Create WildFly and Android apps that can share data.
• Show how to contribute to the app store.
• Show the factories, not just the apps they emit.
• Keep setup notes and source next to a running demo.
• Grow a shared vocabulary for metadata-driven generation.
• Make software factories understandable enough to copy.

How it works

• XML option files provide unique app build information for each app.
• XML build files provide standard app build information for each software builder.
• Also a standard template app provides build information for each software builder.
• Metadata XML options describes entities, field types, and relationships.
• A Groovy generator applies a reusable snippet library from the XML build files.
• The template is overlaid onto the target app and extended in place.
• Build and deploy commands stay in the generated app repo (Android or WildFly).

Think of a 3D printer. Small pieces of code are fused onto the chassis until a product comes out the other side.

What is different here

Other generators usually stamp one stack. These factories share a domain vocabulary and emit two working product lines from close to the same option files.

• One options language, two chassis. Entities, field types, and names are described once. Droid Builder stamps a native Android app. WildFly Builder stamps a Java EE app.
• Paired apps, not two unrelated scaffolds. Booklet, Social, and Security exist on both sides of the catalog. Same product idea, two runtimes.
• They can sync when built. The stamped Android and WildFly apps share the domain, so they can exchange data instead of drifting into two separate models.
• You keep the source. Build and deploy stay in the generated app repo. This is not a hosted low-code canvas and not a one-shot LLM scaffold.

The contract is the options XML. The evidence is the catalog.

Latest docs

Start with the idea, then stamp a server app or a phone app from options.

Latest Android apps

Android Booklet App

Booklet app built with the Android Factory Builder.

App page →

Android Social App

Social app built with the Android Factory Builder.

App page →

Android Security App

Security app built with the Android Factory Builder.

App page →

Latest WildFly apps

WildFly Booklet App

Booklet app built with the WildFly Factory Builder.

App page →

WildFly Social App

Social app built with the WildFly Factory Builder.

App page →

WildFly Security App

Security app built with the WildFly Factory Builder.

App page →