v3.0.0 Migration Guide — io.miragon namespace

v3.0.0 moves bpmn-to-code to the miragon namespace. Nothing about how the plugin works changes — only the published coordinates and package names.

• Maven group: io.github.emaarco → io.miragon
• Gradle plugin id: io.github.emaarco.bpmn-to-code-gradle → io.miragon.bpmn-to-code-gradle
• Generated runtime imports: io.github.emaarco.bpmn.runtime.* → io.miragon.bpmn.runtime.*

Coming from io.github.emaarco?

bpmn-to-code now lives here under io.miragon. If you are still on the old io.github.emaarco coordinates, you can switch at your own pace:

Old surface	Still works after switching to io.miragon?	How
Generated code importing io.github.emaarco.bpmn.runtime.*	✅	The io.miragon runtime jar still ships those types as @Deprecated aliases, so you can switch coordinates without regenerating right away. Removed in 4.0.
io.github.emaarco:* dependency coordinates and id("io.github.emaarco.bpmn-to-code-gradle")	✅ (from the legacy release)	The final io.github.emaarco 3.0.0 is published from the old emaarco/bpmn-to-code repo and redirects to io.miragon. This project itself only publishes io.miragon.

The deprecated runtime aliases are a safety net for an incremental switch, not a place to stay — the old import package is removed in 4.0. Switch coordinates and regenerate per module as described below.

Migrating

Gradle

plugins {
    // before
    id("io.github.emaarco.bpmn-to-code-gradle") version "2.x"
    // after
    id("io.miragon.bpmn-to-code-gradle") version "3.0.0"
}

The plugin auto-adds the io.miragon:bpmn-to-code-runtime dependency for you. After switching, regenerate your Process API (./gradlew generateBpmnModelApi) so the generated imports point at io.miragon.bpmn.runtime.*.

Maven

<plugin>
    <groupId>io.miragon</groupId>
    <artifactId>bpmn-to-code-maven</artifactId>
    <version>3.0.0</version>
</plugin>

If you declared the runtime or testing modules explicitly, update their groupId to io.miragon too, then regenerate (mvn generate-sources).

Regenerate, then drop the old imports

Within a single module, don't mix old- and new-package runtime types — the deprecated io.github.emaarco.bpmn.runtime.ProcessId and the new io.miragon.bpmn.runtime.ProcessId are distinct types. Regenerate the Process API and update your own imports together, in one step per module.

Why

bpmn-to-code is moving under the miragon brand so it can be hosted and supported as a company-backed project. Development continues as before — this is a packaging/branding change, not a change of maintainership or behavior.