Imixs-Workflow: A BPMN 2.0 Engine for Human-Centric Tasks on Jakarta EE

The problem Imixs-Workflow addresses

Human-centric workflow means a process that waits on people, not on timers or message queues. Someone claims a task, edits a record, submits it, and the engine decides what happens next. Imixs-Workflow is built for that shape of problem. The README describes it as an open source workflow engine for building human-centric workflow applications, with business logic modelled in BPMN 2.0 rather than written as branching Java code. The intended audience is a Java team that already has an application server and wants process routing as a component inside it, not as a separate product with its own runtime. That framing matters. A team building a document approval chain, a case file that moves between departments, or an expense claim with several sign-off stages is the target. A team building a data pipeline with retries and backoff is not, even though both are sometimes called workflows. The project also lists ai-agents among its topics, which suggests interest in driving process steps from automated actors, but the README itself says nothing about how that works, so treat it as a direction rather than a documented feature.

BPMN models as the unit of business logic

The design decision at the centre of this project is that the process definition is a BPMN 2.0 model, not Java code. Imixs-BPMN is an Eclipse modelling tool that produces those models, and the README states plainly that these models can be executed by the Imixs-Workflow engine. So the data flow runs in two stages. At design time, someone draws the process in Eclipse and saves a BPMN file. At run time, the engine reads that model and uses it to route work items. This is the standard split you find in BPM suites, and it carries the standard consequence: changing a process means changing a model, and the model has to be deployed to the engine. It also means the engine cannot execute arbitrary BPMN 2.0. The README claims BPMN 2.0 support but does not enumerate which elements the engine understands, so the safe assumption is that a subset is executable and the rest is documentation-only notation. That is a normal limitation for every BPMN engine, but it is the first thing to check against your own process diagrams before you commit. The pluggable-architecture topic in the repository metadata hints at extension points for custom behaviour, but the README does not describe them, so I cannot say what a plugin looks like from the supplied material.

Maven artifacts and what each one does

The engine is consumed as a set of Maven modules rather than a single jar, and the README's dependency example names three of them. imixs-workflow-engine is the core. imixs-workflow-jax-rs provides the RESTful API layer, which the README describes as the way to integrate the engine into a microservice architecture, potentially deployed as a separate service managing human-centric tasks. imixs-workflow-index-lucene is a search index built on Lucene, which implies that work items are queryable and that you are expected to run queries over them rather than just fetch by identifier. The dependency block in the README also ends with an ellipsis, so this is a partial list, not the full set of modules. The version is referenced as ${org.imixs.workflow.version}, a property you define yourself, and the README points to Maven Central for the artifacts. Because the three modules are versioned together under the imixs-workflow release tags, the practical rule is to pin all Imixs dependencies to one version string rather than mixing. Nothing in the README states whether the Lucene index module is optional, but the fact that it is listed separately from the engine suggests you can leave it out if you do not need search.

Building from source and the server prerequisite

Building the project from source is a single Maven command, mvn install, and the README lists the prerequisites as JDK8 or later, Maven 3.0.3 or later, and a Jakarta EE application server. That third prerequisite is the one that shapes adoption. Imixs-Workflow is not a standalone process you launch. It is deployed into Wildfly, Payara, Open Liberty or Apache TomEE, all named in the README, and it targets the Jakarta EE and Eclipse MicroProfile standards. The README also states that version 6.x has full Jakarta EE 9 support and that version 5.2 remains the line for Jakarta EE 8, described as still fully supported. That is a real fork in the road: if your server generation is older, you are on the 5.2 branch, and the 6.2.x releases listed in the repository are not for you. If you would rather not assemble the stack yourself, the Imixs Process Manager is a separate project offering a BPM suite with a generic user interface and a Docker image. The README gives the deployment step as downloading its docker-compose.yml and running docker-compose up. There is also an Imixs-Admin project for administering an instance remotely through a web tool, and an Imixs-Microservice project for a full service stack on Kubernetes or Docker Swarm. Those are separate repositories, not modules of this one.

Where the engine is the wrong choice

The clearest failure mode is environmental. If you do not have a Jakarta EE application server and do not want one, this project asks you to acquire one before it does anything. That is a large prerequisite for a team that just wants to move a record through five states. The Process Manager's docker-compose route softens this, but it is a different repository and a full BPM suite, so you are adopting more surface than the engine alone. A second limitation is the model-driven core itself. If your routing rules depend on data the BPMN model cannot express, or change weekly in ways that make redeploying a model painful, the modelling layer becomes overhead rather than an asset. A third is documentation depth. The README is a landing page. It names the modules, the servers, the build command and the licence, and it defers everything else to the project home. It does not document the REST endpoints, the work item schema, the plugin interface, or which BPMN elements execute. Anyone evaluating this has to go to imixs.org for the parts that decide whether it fits. There is also a versioning trap: a team on Jakarta EE 8 that pulls the latest 6.2.x artifacts will find they do not match their server, and the README's note about version 5.2 is easy to skim past.

How it compares to Camunda and Flowable

The obvious alternatives are Camunda Platform and Flowable, both Java BPMN engines with long histories. The difference is not the notation, since all three execute BPMN 2.0 models. It is the packaging and the centre of gravity. Camunda and Flowable ship an embeddable engine that you can start inside a plain Spring Boot application, with the application server as an option rather than a requirement. Imixs-Workflow is built the other way around: the README frames it as a Jakarta EE and MicroProfile component that fits into an application server, with the microservice deployment offered as an integration pattern through its REST API. If your estate is already Jakarta EE, that alignment is a benefit, because the engine uses the same programming model and deployment unit as the rest of your application. If your estate is Spring Boot, the alignment works against you, and you would be adding a Jakarta EE runtime to host a workflow engine. The second difference is scope. Camunda and Flowable carry their own modelling tools, form builders and operational consoles as first-party products. Imixs splits that across repositories: Imixs-BPMN for modelling, Imixs-Admin for administration, Imixs-Process-Manager for the suite. That is a lighter core, and it also means more moving parts to assemble and track.

Maintenance, releases and licensing

The release cadence visible in the repository is roughly monthly through 2026, with 6.2.6 in May, 6.2.7 in July and 6.2.8 in August, and the last push to master in early September 2026. The project is not archived. The README states that the Jakarta EE 8 line, version 5.2, is still fully supported, which means maintenance effort is split across two server generations. For an adopter that is the main ongoing cost: you track two upgrade paths, and moving from 5.2 to 6.x is a Jakarta namespace migration, not a version bump. There is no dependency-upgrade guide in the supplied material, so the size of that migration is unknown from here. On licensing, the situation needs care. The repository metadata reports the licence as NOASSERTION, while the README states the project is under the Eclipse Public License v. 2.0 and that you may choose to use, modify and distribute it under EPL 2.0 or GPL-2.0-or-later. The README points to a LICENSE.md file for the text. EPL 2.0 is a weak copyleft licence with a secondary-licence option, but how the dual EPL/GPL choice interacts with your own distribution model is a question for your legal team, not something to settle from a badge. Verify the LICENSE.md contents against the version you actually depend on before shipping.

Editorial conclusion

Adopt Imixs-Workflow if you already operate a Jakarta EE 9 application server and want BPMN 2.0 task routing with a REST surface, or if you need the Jakarta EE 8 line that version 5.2 still covers. Do not adopt it if you want a workflow runtime that starts without an application server, or if your process logic lives in code rather than in a BPMN model. Before committing, verify which artifact versions resolve for your server generation, and confirm the actual licence terms on the LICENSE.md file, since the repository metadata reports NOASSERTION while the README names EPL 2.0 with a GPL-2.0-or-later option.

Official sources

1. imixs/imixs-workflow on GitHub
2. Issues
3. Project website
4. README
5. Releases