# wildfly/quickstart: the versioned sample projects behind WildFly

> wildfly/quickstart is the repository holding all versioned WildFly quickstarts, sample Jakarta EE and MicroProfile projects used to demonstrate the application server. It is aimed at developers learning a subsystem by running a working example, and at maintainers who need one source tree that documents both WildFly and JBoss EAP.

**wildfly/quickstart** — Holds all versioned WildFly quickstarts

- Repository: https://github.com/wildfly/quickstart
- Stars: 929 · Forks: 1,358
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/wildfly-quickstart

## One AsciiDoc source, three product audiences

The repository description is brief: it holds all versioned WildFly quickstarts. The interesting part is what the README file actually is. It is not prose documentation, it is an AsciiDoc template full of attribute definitions and conditional blocks, and those blocks decide which product the resulting guide is written for.

At the top of that file sit two flags. The ProductRelease flag, once enabled, builds README.html files for JBoss EAP product builds and is commented out for WildFly builds. The EAPXPRelease flag builds README.html files for EAP XP product builds and is commented out for WildFly or JBoss EAP builds. Between them they select one of three flavours of the same documentation.

That mechanism is the core idea. The same quickstart descriptions, the same build instructions and the same set of links are rendered differently for WildFly, for Red Hat JBoss Enterprise Application Platform and for JBoss EAP XP, and the repository also serves as the source for the separate jboss-eap-quickstarts repository, whose URL is defined as https://github.com/jboss-developer/jboss-eap-quickstarts/.

For a reader, this means the WildFly quickstart documentation you read online is generated from this repository, and the EAP documentation is generated from the same source with different attributes set.

## Attributes carry the product name, version and links

Everything product specific lives in named attributes rather than in the body text. For the WildFly branch, the file defines:

```
:productName: WildFly
:productNameFull: WildFly Application Server
:ProductShortName: {productName}
:jbossHomeName: WILDFLY_HOME
:productVersion: 42
:githubRepoUrl: https://github.com/wildfly/quickstart/
:githubRepoCodeUrl: https://github.com/wildfly/quickstart.git
:WildFlyQuickStartRepoTag: 42.0.0.Beta1
```

The same file carries the equivalent block for the JBoss EAP release, with product version 8.1, a repository tag of 8.1.x and a Helm chart name of jboss-eap/eap81, and a third block for EAP XP with product version 6.0 and a repository tag of XP_6.0.0.GA.

Two details show how carefully this is maintained. The file carries a comment noting that this is a universal name for all releases, so the product short name resolves consistently whether the build is for WildFly or for a Red Hat product. And the WildFly branch explicitly overrides the documentation link attributes to point at the WildFly site, setting the Helm repository URL to http://docs.wildfly.org/wildfly-charts/ and the chart name to wildfly/wildfly, while the product branches point at the Red Hat chart repository instead.

The result is that a contributor edits one file and gets correct documentation for whichever product the build targets.

## A directory per subsystem, from helloworld to microprofile-lra

The top level of the repository is the catalogue. Each quickstart is its own directory, and the names read like an index of Jakarta EE and MicroProfile rather than like projects you would find on a portfolio site.

The entry points are the helloworld family: helloworld, helloworld-jms, helloworld-mdb, helloworld-rs, helloworld-singleton, helloworld-ws, helloworld-mutual-ssl and helloworld-mutual-ssl-secured. Around them sit the enterprise JavaBeans examples such as ejb-multi-server, ejb-remote, ejb-security-context-propagation, ejb-security-programmatic-auth, ejb-throws-exception, ejb-timer and ejb-txn-remote-call, plus the JAX-RS and JAX-WS clients, jaxrs-client and jaxrs-jwt, and jaxws-ejb and jaxws-retail.

Then there is the operations side of the catalogue: batch-processing, bmt and cmt for transaction demarcation, ha-singleton-deployment and ha-singleton-service, ee-security, http-custom-mechanism, jta-crash-rec, logging, mail, messaging-clustering-singleton, micrometer, and the microprofile block covering config, fault-tolerance, health, jwt, lra and openapi.

There are also bundles rather than single features, hibernate, jsonp, jts and kitchensink. A kitchen sink example is a good way to see how several subsystems interact in one deployment, and it is a useful contrast to the deliberately narrow examples next to it.

## Java 17 and Maven 3.6 are the stated build requirements

The requirements are stated in the same attribute block:

```
:buildRequirements: Java SE 17.0 or later, and Maven 3.6.0 or later
:javaVersion: Jakarta EE 11
```

That Jakarta EE 11 line is replaced for the EAP XP build, where the attribute is set to Eclipse MicroProfile instead, which tells you the product branches target a different specification surface rather than the same code with different branding.

The minimum versions matter more than they look. Java SE 17 is the floor, and Jakarta EE 11 is what the WildFly 42 line targets, so a quickstart from this branch will not run on an older server or an older JDK without changes. That is also why the repository is versioned: each quickstart directory is maintained against the release it belongs to, and the WildFlyQuickStartRepoTag attribute points at the matching tag for the branch being built.

The build itself is not described in this repository's README. The file instead points to shared guides hosted in the jboss-developer-shared-resources repository, including a guide on using Red Hat JBoss Developer Studio or Eclipse to run the quickstarts, one on deploying and undeploying a quickstart containing server and Java client projects, and one on configuring Maven to build and deploy the quickstarts. There are also links for creating the users the quickstarts require, both an application user and a management user, for starting the server, and for configuring PostgreSQL, including how to add the postgres module and the driver.

## OpenShift deployment references, Helm charts and guides

The template also carries the variables used for the OpenShift sections, which are generated from the same attributes. They include the book links for Getting Started with the product on OpenShift Container Platform and on OpenShift Online, the name of the container registry, and separate guide links for each.

The Helm chart identifiers are part of the same mechanism. The WildFly build points at the chart repository http://docs.wildfly.org/wildfly-charts/ and the chart wildfly/wildfly, while the EAP build uses the jboss-eap repository and the eap81 chart. A reader can therefore see, from one file, which chart corresponds to which product and version.

The Byteman and PostgreSQL links deserve a note because they show the shape of the quickstarts. These examples are not self-contained. The guides cover downloading and configuring Byteman, and the PostgreSQL path has separate steps for installing the database, creating a database user, adding the postgres module to the server and configuring the driver inside it. A quickstart that needs an external database teaches you the integration, not just the API, which is the point of having it, but it also means each example has prerequisites beyond the server itself.

## Release procedure, security policy and the CI wiring

The repository carries the housekeeping files a shared, multi-contributor project needs: `CONTRIBUTING.adoc`, `CODE_OF_CONDUCT.adoc`, `SECURITY.adoc`, `dco.txt`, `contributor-settings.xml`, `CODEOWNERS`, `AGENTS.md`, `LICENSE.txt` and a `.gitleaks.toml` for secret scanning. There is also a `RELEASE_PROCEDURE.adoc`, which documents how a release is cut, and a `_context/` directory holding the shared AsciiDoc context that the per-product builds pull in.

The `dist/` directory is where the built documentation artifacts live, and `guide/` holds guide sources. A `.ci/` directory and a `.github/` directory sit alongside them.

The releases follow the WildFly versioning scheme rather than semver. The list shows 42.0.0.Beta1 published on 2026-10-08, 41.0.1.Final-SP1 on 2026-08-26 and 41.0.0.Final on 2026-07-16, and the last push was on 2026-10-19. The Beta tag in the current release matters for anyone binding to it: the quickstart repository moves to a new major as the server does, and the tag attribute in the README is how the build knows which one to point at.

## Apache-2.0 terms and what a quickstart is not

The licence field on the repository says Apache-2.0, and the repository carries a LICENSE.txt and a NOTICE file. Since these projects exist to be copied, that matters more than it would for a library: you can take a quickstart, change it, and use it in a proprietary application without the copyleft obligations that a GPL-style licence would impose.

What you should not expect is a production skeleton. These are teaching examples with a consistent build and deployment convention, meant to be read as much as run. The names make the intent clear, with helloworld, ejb-throws-exception and jta-crash-rec each isolating one behaviour so that a reader can see the mechanism without unrelated code in the way.

Two constraints deserve to be stated plainly. The first is that the repository is version locked to a server line. The README sets the product version to 42 and the repository tag to 42.0.0.Beta1, so a quickstart from the main branch is not guaranteed to match a WildFly release you actually run, and the tagged branches are the ones aligned with a given server version. The second is that the instructions for building and running live in a separate shared guides repository rather than here, so a reader following only this repository will not find the full run procedure in one place.

Neither point makes the project less useful. It makes it a documentation companion to WildFly rather than a standalone application template, which is what it is meant to be.

## Conclusion

Adopt wildfly/quickstart as your reference set when you are building on WildFly 42 with Jakarta EE 11 and want a runnable example for each subsystem instead of a paragraph of documentation. Skip it if you need a production skeleton, since these are teaching examples with their own build conventions, or if you are on a different WildFly major version and need the matching tag. Verify first that your toolchain matches the stated requirement of Java SE 17.0 or later and Maven 3.6.0 or later, and pick the repository tag that matches the server version you run. The licence field on the repository says Apache-2.0, the last push was on 2026-10-19, and the current release is 42.0.0.Beta1.

## FAQ

### What is in the wildfly/quickstart repository?

It holds all versioned WildFly quickstarts, with one directory per example. The top level includes helloworld variants, EJB examples such as ejb-multi-server and ejb-timer, jaxrs-client, jaxws-ejb, batch-processing, bmt, cmt, hibernate, jta-crash-rec, micrometer and microprofile quickstarts for config, fault-tolerance, health, jwt, lra and openapi.

### What do I need to build the WildFly quickstarts?

The build requirements are given as Java SE 17.0 or later, and Maven 3.6.0 or later. The documented Java version for the WildFly build is Jakarta EE 11, with the EAP XP build using Eclipse MicroProfile instead.

### Which WildFly version do the quickstarts target?

The README sets the product version to 42 and the repository tag attribute to 42.0.0.Beta1. The tagged releases listed are 42.0.0.Beta1 on 2026-10-08, 41.0.1.Final-SP1 on 2026-08-26 and 41.0.0.Final on 2026-07-16.

### How are the WildFly and JBoss EAP versions of the documentation generated?

The README file is an AsciiDoc template with conditional blocks. A ProductRelease flag builds the README.html files for JBoss EAP product builds and is commented out for WildFly, and an EAPXPRelease flag does the same for EAP XP builds. Product names, versions, repository tags and Helm chart identifiers are set as attributes for each branch.

### Where are the instructions for running a quickstart?

The repository README links to shared guides hosted in the jboss-developer-shared-resources repository, covering running the quickstarts in Red Hat JBoss Developer Studio or Eclipse, deploying a quickstart containing server and Java client projects, configuring Maven to build and deploy, creating the required application and management users, starting the server, and configuring PostgreSQL.

### What licence applies to the WildFly quickstarts?

The licence field on the repository says Apache-2.0, with a LICENSE.txt and a NOTICE file at the top level. The repository also carries CONTRIBUTING.adoc, CODE_OF_CONDUCT.adoc, SECURITY.adoc and a RELEASE_PROCEDURE.adoc.

## Sources

- [Issues](https://github.com/wildfly/quickstart/issues)
- [License: Apache-2.0](https://github.com/wildfly/quickstart/blob/main/LICENSE)
- [README](https://github.com/wildfly/quickstart/blob/main/README.md)
- [Releases](https://github.com/wildfly/quickstart/releases)
- [wildfly/quickstart on GitHub](https://github.com/wildfly/quickstart)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wildfly-quickstart