WildFly: one Maven build leaves you two directories and two ways to start it

Two run modes, and a shutdown issued through a script with the old name

After a successful build you change into the bin directory under the build output and pick a script. One script starts the server in domain mode and the other starts it in standalone mode, and the README gives both without explaining the difference between them, deferring to the getting started guide for that. Stopping is equally short: press Ctrl and C, or use the admin console through the command line, whose invocation takes a connect flag followed by a shutdown command:

$ cd build/target/wildfly-\[version\]/bin
./domain.sh
./standalone.sh
./jboss-cli.sh --connect command=:shutdown

The command line script is still named after the product's predecessor, which is the only place in this file where that older name appears, and it is the sort of continuity that makes an installer's job harder than it needs to be.

One build produces two directories and the README says which to use

This is the part of the document worth reading twice. After the Maven install runs, the server is available in two distinct directories. The build directory holds a version of the server whose module configuration is based on Maven artifact resolution, while the dist directory holds a full distributable build. The trade-off is stated in one sentence each: using the build directory makes iterating with subsystem or module development easier, because there is no need to rebuild the whole server or copy jar files around on every change, while the dist directory is better suited when a full build is needed for development or test purposes. So the default choice for a contributor and the default choice for a tester are different, and the README does not pretend otherwise.

The Maven floor and the Maven recommendation are years apart

The prerequisites are three items and one of them is an operating system limit. You need a JDK at version 17 or newer, checked by asking the tool for its version, and Maven at 3.6.0 or newer, checked the same way, with the note that Maven 3.9.14 or a higher Maven 3 is recommended. That is a floor and a recommendation more than three years of releases apart, which leaves a wide span of versions that work but are not what the project has in mind. On Unix-like systems the build also needs the open file limit for the user running the build to be at least 4096, or more if other input and output heavy processes are running, and the README says to check it with the shell's limit command. The build itself is one command, or the wrapper script, which fetches the required Maven version into a directory under your home and runs it from there.

One flag separates the smoke test from the whole suite

The testsuite is described in three sentences. For basic smoke tests you run the ordinary test command. To run all the tests you run the install command with a property that switches the full suite on. And the testsuite module contains several submodules which can be run individually as needed in order to speed up development. That third point is the operationally interesting one: the suite is designed to be entered at submodule level rather than only at the top, which is what makes a change to one subsystem testable without waiting for everything. The README links a document describing the testsuite in detail, and the tree shows where that document lives, in the documentation sources as an asciidoc file rather than on the published site.

A documentation link in the README is marked temporary by a comment

Immediately after that testsuite link there is a line that is not part of the document a reader sees. It is a comment marker holding a note that the link should be replaced with the published version of the section once the project publishes it with a permanent address. So the repository contains a visible TODO about its own documentation, in the one place where a reader would go to learn how to run the suite. It is a small thing and an honest one, since the alternative is a link that silently rots, but it does mean the path in the README is known by the project itself to be temporary.

The module list is a Jakarta EE tree and a MicroProfile tree side by side

The top level is where the project's shape is visible. Two parallel families of directories exist: a set whose names begin with ee, covering the full profile, its build, its distribution, its feature pack and its security variants, and a single microprofile directory beside them. Around those sit the integration modules a Jakarta EE server needs, and the list is long enough to be the real documentation: a directory each for Jakarta Data, REST services, persistence, faces, enterprise beans, batch processing, messaging, a datasource pool, a clustering module, a connector module, naming, mail, health, metrics, observability, load balancing, an OIDC client, CORBA services, bean validation, concurrency and plain old Java objects. Two entries are about diagnostics and packaging rather than features: a report directory and a provisioning pack directory.

Three shell scripts at the root, and a secret scanning configuration

A Java project with a dozen directories of code still carries a handful of loose files at the root, and they are worth naming. There are two build scripts, one for Unix and one for Windows, and two more for integration tests in the same pair. A third script checks logging, which suggests the project has automated checks over what gets written where. Beside them sit a Checkstyle suppressions file, a secret scanning configuration, a Maven wrapper directory and its two wrapper scripts, and an editor configuration directory committed alongside everything else. One loose source file is also at the root, a class whose name says it updates checksums, which is consistent with the secret scanning configuration sitting above it.

Three releases in two months, each with a qualifier inside the version

The release names are the interesting part. The newest is 41.0.1.Final, published in late August 2026, preceded by 41.0.0.Final in July and 41.0.0.Beta1 in June. So the qualifier is part of the version string rather than a label beside it, and a beta of the same version number sorts next to the final it precedes. Three releases inside two months is a fast cadence for an application server, and it is the sort of pattern that breaks a pipeline which assumes the last numeric component is the only thing that changes. The repository's own paperwork is thorough by contrast: a developer certificate of origin file for signers, a licence file under Apache 2.0, a security policy, a code of conduct, and a separate file crediting contributors under a permissive licence.

Editorial conclusion

Treat this repository as the inside view of the server's build, not as an operating manual. What it gives a contributor is precise and useful: which JDK and Maven to use, which of the two build outputs to develop against, how the two run modes differ in invocation, and how to run one test or all of them. What it does not give is deployment or configuration guidance, which lives on the documentation site instead. Two things to settle early. The recommended Maven is more than three years newer than the stated floor, so pick one deliberately. And the three newest releases put a qualifier inside the version string, which matters if anything in your pipeline matches on release names.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wildfly/wildfly on GitHub