Imixs-Workflow is a BPMN engine shipped as Maven artifacts for Jakarta EE

You depend on artifacts, there is no distribution to install

The engine is consumed the way any Java library is. Artifacts sit in Maven Central and you add the ones you need to your own project, for example the engine, the JAX-RS integration and an index module:

<dependency>
    <groupId>org.imixs.workflow</groupId>
    <artifactId>imixs-workflow-engine</artifactId>
    <version>${org.imixs.workflow.version}</version>
</dependency>
<dependency>
    <groupId>org.imixs.workflow</groupId>
    <artifactId>imixs-workflow-jax-rs</artifactId>
    <version>${org.imixs.workflow.version}</version>
</dependency>
<dependency>
    <groupId>org.imixs.workflow</groupId>
    <artifactId>imixs-workflow-index-lucene</artifactId>
    <version>${org.imixs.workflow.version}</version>
</dependency>

Building from source is a single Maven goal, `mvn install`, and the stated prerequisites are JDK 8 or newer, Maven 3.0.3 or newer, and a Jakarta EE application server.

That last prerequisite is the one to sit with. This is a library that expects a servlet-capable runtime, not a standalone process you start alongside your service. The project name it is listed under on Maven Central is `imixs-workflow`, and releases are tagged as `imixs-workflow-6.2.9` and similar.

Jakarta EE 9 is the current line, and 5.2 is the escape hatch

The version story is explicit in the README and it is the first thing to check against your own server.

Full Jakarta EE 9 support is claimed for the current line, which is what lets the engine run on the modern application servers named: Wildfly, Payara, Open Liberty and Apache TomEE. If your server implements Jakarta EE 8 instead, the documented answer is version 5.2, and the README says that version is still fully supported.

So the choice is not between versions of the engine on features. It is between the Jakarta EE 9 line and the Jakarta EE 8 line, and it is decided by your runtime rather than by you. That matters for maintenance planning, because staying on 5.2 to hold an EE 8 server means choosing a branch that is supported but not current.

The design leans on Jakarta EE and Eclipse MicroProfile rather than on a proprietary container API, which is the stated reason it fits a microservice architecture. That claim is about standards alignment, not about providing a microservice distribution, and the repository does not contain one. The README also carries two typos worth noticing as a signal of how carefully maintained the prose is: it says Imixs-Worflow and spells Jakarta as Jakarata in one place.

Lucene or Solr is a module decision, not a config flag

Task work in a human-centric engine accumulates faster than a database query alone handles comfortably, so this project ships two index implementations as separate modules: `imixs-workflow-index-lucene` and `imixs-workflow-index-solr`.

Making it a module choice rather than a setting is a reasonable boundary. An embedded Lucene index lives inside your application server and needs no separate service, which is the simplest deployment and the reason the dependency snippet above names it. The Solr module is there for the case where you already run Solr, or where you want search indexing and querying handled by a service you can scale and back up independently.

Neither is described in detail in the README. There is no comparison of the two, no statement about whether the query API is identical across them, and no note on what happens to existing indexes if you switch. If your application will build queries against the task API, that is worth confirming in the source or the project home before you commit, because changing module later is not a small change if the index implementation leaks into your query code.

The face module, `imixs-workflow-faces`, is the JavaServer Faces layer, which tells you the UI story is also inside the engine rather than in a separate frontend.

The modeler, the admin UI and the service are four other repositories

Most of what a user touches lives outside this repository, and knowing which is which saves an afternoon of searching the wrong tree.

Imixs-BPMN is an Eclipse modelling tool for designing processes in BPMN 2.0, and the models it produces are what the engine executes. Imixs-Admin is a web-based tool for administering a running Imixs-Workflow instance remotely. The Imixs Process Manager is the all-in-one option: a business process management suite for development, test and production that starts quickly and provides a generic user interface described as easy to adapt.

Then there is the microservice route. The README notes that Imixs-Workflow provides a RESTful API so the engine can run as its own service managing human-centric workflow tasks in a microservice architecture, and points at the Imixs-Microservice project for the full stack on Kubernetes or Docker Swarm, with an image on Docker Hub.

So the engine is not opinionated about running as a monolith or a service. What it provides is the API and the artifacts, and the packaging is your decision.

The JAX-RS module in the dependency list is what makes that second option real.

docker-compose starts the Process Manager, not the engine

The one command in the README runs something other than the engine, and it is easy to misread:

$ docker-compose up

That is for the Imixs Process Manager project, downloaded from that repository, and the Process Manager comes with a Docker image that can be deployed locally or into something like Docker Swarm or Kubernetes.

Which gives a clear picture of the adoption path. If you want something to look at in a few minutes, the Process Manager is the entry point, and it is a separate repository with its own compose file. If you want the engine in your own application, you add the Maven artifacts and deploy your own WAR or application.

The microservice image is the third option again, separate project, separate Docker Hub repository, and the README does not compare the three or recommend one.

One detail about the deployment file name is worth copying correctly: the README links the Process Manager compose file as `docker-compose.yaml` while the command it shows is the older `docker-compose up` invocation. Both exist in the wild and the hyphenated and non-hyphenated forms are not interchangeable across tooling versions, so read that repository's own instructions rather than assuming.

Travis is still in the tree while the badge points at Actions

The repository carries a `.travis.yml` at the root and the README's build badge points at a GitHub Actions workflow file for Maven. Both cannot be the current build.

The README badge resolves to `github.com/imixs/imixs-workflow/actions/workflows/maven.yml`, so GitHub Actions is what runs the build now, and the Travis file is a leftover. That is ordinary and harmless, except that a `.travis.yml` next to an Actions workflow makes a new contributor's first guess about the build wrong.

Other root files give a better picture of what the maintainers treat as load-bearing. There are two code style and checkstyle configurations, `imixs-checkstyle-8.44.xml` and `imixs-code-style.xml`, an `update-license.sh` script, a `COPYRIGHT` file, and `MIGRATIONNOTES.md` alongside `SECURITY.md`.

Migration notes are the file to read first if you are upgrading across a major version, because this project tracks a Jakarta EE line change, and those changes break things. `ISSUE_922.md` sitting in the root suggests unresolved issues get parked at the top level rather than only in the tracker.

Releases are frequent: 6.2.9 on 2026-09-19, 6.2.8 on 2026-08-28 and 6.2.7 on 2026-07-25, with the last push on 2026-09-25.

Dual licensed EPL 2.0 or GPL-2.0-or-later, which is why tools cannot classify it

The licence section says Imixs-Workflow is free software and that results are provided under the Eclipse Public License 2.0, with the choice to use, modify and distribute under EPL 2.0 or GPL-2.0-or-later.

That is a dual licence, and it is the better of the two options for most adopters: EPL 2.0 is file-level copyleft, so modifying the engine files obliges you to publish those files, while the GPL alternative lets you treat the whole combined work as GPL if that suits your distribution model. Which one you take is your decision, and the README grants both without conditions.

It also explains why the repository's licence metadata is inconclusive. A single-identifier field cannot express a choice between EPL-2.0 and GPL-2.0-or-later, so automated tooling reports the licence as unasserted rather than picking one. Check `LICENSE.md` yourself rather than trusting a dependency scanner's summary here.

For a component you deploy inside an application server, the practical question is whether your own application is distributed. If it is not, EPL 2.0 imposes almost nothing on you, since you are not shipping the engine files separately.

Editorial conclusion

Adopt Imixs-Workflow if you run a Jakarta EE application server, model processes in BPMN 2.0, and want task-level search over human work items rather than a distributed workflow service. Do not adopt it if you are starting a greenfield microservice stack, because the engine expects an application server and the microservice packaging is a separate repository you would evaluate on its own. Verify first which Jakarta EE line your server implements, since the current major version needs Jakarta EE 9 and the Jakarta EE 8 path is the 5.2 line, then decide between the Lucene and Solr index modules before you write your first query against the task API.

Frequently asked questions

Official sources

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