[GiulioRinalduzzi]

What

Three constraints in bom/build.gradle:

• io.camunda:zeebe-exporter-api — the Exporter / Context / Controller interfaces
• io.camunda:zeebe-protocol — the Record types the broker hands to export()
• io.prometheus:simpleclient (0.16.0) — the legacy metrics client the Zeebe broker ships

The first two follow the same zeebeVersion (8.4.17) the Zeebe clients already use, purely for consistency — not because they have to match the running broker. They are compileOnly in the exporter, so the broker supplies the classes at runtime; the Exporter SPI is stable across the 8.x line, and the exporter deployed today is built against 8.1.1 and runs fine in a broker that is not 8.1. Nothing in this repository sets the broker's version anyway — that is the chart's image tag. (An earlier revision of this PR claimed they must match; the comments in the build files are corrected too.) simpleclient is pinned: Spring Boot 3 manages the newer io.prometheus:prometheus-metrics-* line instead, so the legacy client is not governed by the imported Spring Boot BOM.

Why

The Kafka exporter in paymenthub-ee-data-pipeline is a broker plugin, not a service: the broker loads its jar from disk and runs it inside its own JVM. So it compiles against those three, as compileOnly, with no version of its own. Without these constraints its build fails with Could not find io.camunda:zeebe-exporter-api: — an empty version.

The alternative would be pinning the versions in that module's build.gradle, which the migration rules rule out: every version comes from this BOM.

This is a prerequisite for openMF/paymenthub-ee-data-pipeline#1.

One thing worth a decision before merging

A note from the zeebe thread — David said: "On camunda we need to check license terms they changed around then which is why we are looking at workflow abstraction".

This PR pulls the broker's internal SPI into the BOM, so it deepens exactly the Camunda coupling a workflow abstraction would want to remove. The exporter is the only component in the whole migration that touches that SPI — everything else is client-side (zeebe-client-java, spring-zeebe-starter) and would sit behind an abstraction unchanged.

I had parked this PR for that reason and am opening it because the data-pipeline PR is meant to carry all four components. If you would rather keep the broker APIs out of the BOM until the abstraction decision is made, say so and I will drop the exporter from that PR instead — the other three modules do not need anything here.

Nothing in this PR moves anyone onto a newer Camunda: zeebeVersion stays 8.4.17.

Update. The ticket to package the exporter as a self-contained Zeebe 8.5 image gives it its own repository (paymenthub-ee-exporter-zeebe) with the Shadow plugin, which means it can pin these three itself. Nothing else in the migration declares zeebe-exporter-api, zeebe-protocol, simpleclient or org.apache.kafka:kafka-clients directly — the other Kafka users go through spring-kafka, which the Spring Boot BOM already manages. So if the exporter moves out, this PR can be closed rather than merged, and the broker SPI stays out of the BOM, which is what the workflow-abstraction concern wanted. Holding here until that is decided.

Verified

./gradlew :bom:verifyBom green, 245 artifacts, 0 javax. Published to a local Artifactory and the exporter module compiles against it (clean build, fat jar produced).

[tdaly61]

@GiulioRinalduzzi , @DavidH-1 this is not the way I was originally thinking about handling exporter.jar ..but I want to get this into our dev branch and which should allow the openMF/paymenthub-ee-data-pipeline#1 to be merged and operate. My logic is that we can adjust this when I have a better handle on it. Thanks for making sure we are only at zeebe Giulio as David, this is still the permissive zeebe license