OpenWMS and the business component approach to warehouse software

This repository is documentation plus one shared library

The first thing to understand about org.openwms is that it is not the warehouse management system itself. It is the root repository of the OpenWMS.org project, and the readme is explicit about what it contains: project-level documentation and a single Maven module, the `org.openwms.core.util` library, which holds utility classes, exception types and common event types shared by all the other OpenWMS.org services.

The business services live in their own repositories, listed in a table. The Service Registry, the Configuration Service, the Gateway Service, the UAA Service and the Preference Service are all separate projects with their own release tags, and each row in the table records its accessibility and its licence. Several of them are public and Apache-2.0, while the Auth Service and an ENTERPRISE variant of the Gateway Service are marked private and GPLv3, with no version tag shown.

That table is the single most important thing to read before evaluating the project, because it defines the adoption surface. The pieces you would actually run are scattered across half a dozen repositories, and the split is not merely organisational. Two of them are not openly available at all.

The project describes itself as a free to use and extensible Warehouse Management System with an MFC system for automatic and manual warehouses, and points to a wiki for further documentation of the business services. The top level layout is consistent with that: a `doc/` directory, a `scripts/` directory, `pom.xml`, the Maven wrapper files `mvnw` and `mvnw.cmd`, a `.mvn/` directory, and the one module directory `org.openwms.core.util/`.

So if you are evaluating "OpenWMS", you are evaluating a family of services plus a shared library, and the flagship features live in the other repositories.

Building means JDK 25 and one wrapper command

The build requirement is stated in one line and it is a high one: building requires JDK 25 and uses the Maven wrapper. The command is:

./mvnw clean verify -DsurefireArgs=-Dspring.profiles.active=ASYNCHRONOUS,TEST

Two things are packed into that line. The wrapper itself means you do not need a locally installed Maven, which removes one version mismatch from the setup. The `spring.profiles.active` argument sets the Spring profile to `ASYNCHRONOUS,TEST` for the test run, which tells the application under test to use its asynchronous event handling and its test configuration rather than whatever the default profile would pick.

That profile switch is a hint about how the system behaves, because the asynchronous path is the normal one. The technology section says RabbitMQ in combination with Spring Integration is used as the event broker for asynchronous event and command propagation, so a test run that exercises the asynchronous profile is exercising the same propagation mechanism the running system uses.

The build is also fully version managed from outside. The remote parent POM `org.openwms:org.openwms.parent` manages all plugin and dependency versions, and snapshot artifacts are deployed to the Sonatype Central snapshot repository on every push to `master`. So a contributor does not pick dependency versions, the parent POM does, and a `master` build publishes a consumable snapshot rather than only a passing test run.

There is a `sonar-project.properties` file at the root, so static analysis is configured for the project, and a `src/` directory alongside the module, which is where the shared library's sources live.

Business components instead of technical layers

The architecture section is where this project makes a choice that shapes everything downstream, and it is a choice about how to cut a system up.

Instead of applying a technical layered architecture, the current architecture focuses on business components. Business functions with a high cohesion are kept together as small deployable software components, and each component has its own development lifecycle, its own roadmap of API evolution, and a separate data store.

Read that carefully, because the separate data store is the load-bearing part. These are not modules inside one application sharing one schema. Each is a service that owns its data, and that is why they are described as microservices following the Twelve-Factor methodology, with each functional business component managed within its own SDLC and its own source code repository.

The consequence for a user is that there is no single database to inspect and no single process to restart. A change to the routing decision logic is a change to one service. A change to the inventory model is a change to another, and it may or may not need a coordinated release. The benefit of that structure is that you can adopt or replace one piece without taking the rest apart.

The surrounding context matters too. ERP systems sit above and send high-level tasks, for example a customer order with order lines referring to products managed by the Inventory Service, and OpenWMS.org fulfils those tasks by orchestrating the underlying subsystems. The communication can run both ways: OpenWMS.org may send status messages back to the ERP, or request product catalog updates, depending on the project's needs.

So the model is ERP on top, a set of business services in the middle, and devices on the bottom.

The device layer is where response times stop being negotiable

The bottom of the architecture sketch connects to devices that sit close to actors and sensors in automatic warehouses. The readme is blunt about the constraint: these devices are almost limited in hardware resources and protocol stacks, and they expect response times in the range of milliseconds to control motors and switch gates very quickly.

The security reasoning follows directly from that. Such subsystems have the power to bring down a serving component just by repeating requests all the time, and the readme contrasts them with typical web application clients, where the infrastructure handles denial of service and the application server pools incoming traffic.

So the rule for anything at the device edge is that it must not be chatty. A service that a PLC polls is in a different risk position from a service behind a browser, and the architecture has to respect that, which is part of why the event broker exists at all.

The hardware preference is open source. OpenWMS.org promotes the usage of open source hardware components over commercial PLC products, and the first choice of supported devices are boards with an open microcontroller architecture, naming Raspberry Pi and the industrial Revolution Pi. Closed proprietary systems are supported as well, so the open hardware preference is a preference rather than a restriction.

This is also the part of the system most likely to need a specific piece of hardware knowledge, since the readme points to each component's own GitHub page for the details of its architecture and design.

Java 25, Spring Boot 4.1, RabbitMQ and three named PaaS targets

The technology baseline is current and specific: Java 25 and Spring Boot 4.1, plus a bunch of Spring Framework subprojects.

The workflow engines are a notable inclusion, because routing decisions on the transport layer are exactly the kind of thing that a warehouse needs to be able to change without a code deployment. The supported engines are Activiti, Flowable and Camunda, so the project does not lock you into one.

Persistence is described with a similar openness. RDBMS access is most often realised with the Jakarta Persistence API, and some components might also use NoSQL databases such as MongoDB. That word most often is doing real work: the persistence choice is per component, not global.

The event broker is RabbitMQ in combination with the Spring Integration project, used for asynchronous event and command propagation. Given the device layer's millisecond expectation, the asynchronous broker is the mechanism that keeps a slow device from becoming a slow request path.

All microservices are realised as Spring Boot applications designed to run on any modern PaaS cloud platform, and three are named: Azure Kubernetes Service, AWS EKS and Redhat OpenShift. The claim is that they run on any modern PaaS, and the three examples tell you what the project actually tests against.

For a team choosing a stack, the summary is that you inherit Java 25, Spring Boot 4.1, a BPMN engine, Jakarta Persistence and RabbitMQ, and you inherit the requirement that your runtime platform can run Spring Boot applications on Kubernetes or OpenShift.

Why the public and private split is the adoption decision

The services table records accessibility and licence per component, and the pattern in it deserves attention rather than a passing mention.

The public, Apache-2.0 services include the Service Registry, the Configuration Service, the Gateway Service, the UAA Service and the Preference Service. The Auth Service is private and GPLv3, and so is the Gateway Service ENTERPRISE variant, which points at a different organisation's repository than the public gateway does. Two rows in the visible part of the table carry no version tag at all, which is consistent with them not being openly released.

The licensing split is not an accident of history, it is a business model. The openly available services cover the parts a developer needs to build against and extend, and the authentication and enterprise gateway pieces are where the commercial value sits. That is a common and defensible arrangement for a company-backed open source project, but it has a concrete consequence for evaluation: the set of services you can actually read and run is smaller than the set the architecture describes.

The practical question for an adopter is therefore not "is OpenWMS good" but "which of my required capabilities live in a component I can obtain, and which do not". If your deployment needs the Auth Service and it is not openly available, that is a conversation with the vendor rather than a build decision, and it is better to have it before designing around the architecture.

The root repository itself is Apache-2.0, with the `LICENSE` file at the top level, and the shared utility library it carries is the piece most likely to be consumed directly by someone writing an extension, since it holds the common event types the services exchange.

Editorial conclusion

OpenWMS.org fits an organisation that already runs an ERP, has warehouse hardware on the floor, and wants flow control between goods and storage as a set of services it can extend one component at a time. It is the wrong choice for a small warehouse that wants one application with one database, because the components each carry their own data store and their own deployment. Before starting, verify three things: that the services you actually need are the public Apache-2.0 ones rather than the private GPLv3 Auth and ENTERPRISE gateway builds, that your PaaS target is one of the three named, and that the Java 25 and Spring Boot 4.1 baseline is compatible with the rest of your stack, since building requires JDK 25. The root repository is Apache-2.0, the last push was on 2026-07-13, and the most recent release was 3.0.0 on 2025-02-22.

Frequently asked questions

Official sources

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