Quick heads-up to everyone using camunda-platform-7-mockito in your tests: We’ve archived the original repository in the Camunda Community Hub and moved active development to our new monorepo:

• Old (archived): camunda-community-hub/camunda-platform-7-mockito
• New (active): holunda-io/c7-mockito

Why we’re doing this

Camunda Platform 7 Community Edition (CE) reached End of Life with 7.24. That means there won’t be any functional development for CE anymore. Future Camunda 7 releases will be Enterprise Edition only.

We do not see any use in developing new features for a discontinued CE version. However, if you are an enterprise customer and use some of our camunda extensions, you will need new releases of the extensions as well, as we need to keep the code base compatible with new camunda releases and 3rd party versions.

The c7 monorepo is our “one stop shop” for these libraries going forward, so we can keep things consistent and reduce maintenance overhead.

Action for your projects

If you reference the old repo in docs or links, please update them to point to:

<groupId>io.holunda.c7</groupId>
<artifactId>c7-mockito</artifactId>
<version>2025.12.1</version>

That’s all for now, we kept the code base unchanged, so you do not have to change anything. Please note that with upcoming 2026 releases, we wil have a breaking change due to changing packages and artifacts!

Thanks to everyone who’s been using and contributing to camunda-platform-7-mockito — see you in the new home. 👋

I first unveiled this real-life story while kicking off my talk, “Meta Programming — Code Generation with Kotlin Poet,” at this year’s Code Talks conference. Since I’ve been retelling this tale in various discussions, I thought it’s high time to share it with a broader audience. So, gather around, grab a cup of coffee, and let’s dive in…

Earlier this year, at Holisticon, we hosted Girls and Boys Day. If you’re not familiar, this is an event in Hamburg where seventh graders visit their families, friends, and relatives at their workplaces to observe how adults spend their day and gain insights into the world of work. Given our expertise in process automation and natural language processing at Holisticon, we assigned them the task of implementing a process, or more precisely, this process:

So, here’s basically how this BPMN process works:

• you send an email informing us that you’re expecting three guests for dinner (e.g.: one is vegetarian, one doesn’t consume alcohol, and one prefers chicken)
• Chat GPT then analyses your request, suggests a meal, provides a recipe, and even generates a grocery list for the items you need to shop.
• The kids also explored letting GPT translate this into French or Spanish …

While this is essentially a fun project, the underlying technology is astonishing. You can find more information about it here.

The kids spent a few hours implementing this process, and it worked seamlessly. They could send an email and receive a response from Chat GPT, instructing them on what to cook, how to prepare it, and what to shop for.
We were all thrilled, and the kids were rightfully proud.

We were impressed: “Wow, this is incredible. What an exciting time to be alive!”

However, once I returned home, I couldn’t shake the thought: “Wait a minute — a bunch of 12-year-olds just constructed a functioning process application that serves its intended purpose, deployed it to the cloud, and executed it.
This is what I do for a living! If children can achieve this today, what will happen in another week or year? My managers and clients might acquire this skill, and I’ll find myself unemployed and starving.”

So, that night, I went to bed feeling frustrated and anxious. Yet, when I awoke the next day, a different concern struck me:

Wait a minute — I didn’t see any food.

We were all impressed by the shiny emails, recipes, and shopping lists, but the crucial question remained:

• Is the food tasty?
• Does it provide enough for three people?
• Can we cook the meal with the items on the grocery list?
• If I were to build a business around this concept, how many customers might I lose every month due to dissatisfaction with my service?

I wholeheartedly agree that we must reduce manual coding. Charging three-digit hourly rates for tasks that any child could copy and paste from a chat page is no longer sustainable. This isn’t necessarily a bad thing; many of the boring, error-prone tasks we currently perform every day should be automated. (Yes, Liquibase, I’m talking to you!)

Nonetheless, it’s our responsibility to ensure that the entire software generation process becomes deterministic, reproducible, and scalable.

That’s where I left off in September. During my conference talk, I emphasized the importance of controlling the generative process, preferably by writing the generators ourselves (you can watch the video for more).

What now?

Let me break it down in simpler terms: We’re entering a world where 2 plus 2 might not always equal 4 anymore.
The result may vary depending on what the customer wants, what they are willing to pay, and how we design the system. It also could be any value between 3.8 or 4.2.

We need to determine if this tolerance is acceptable, establish mechanisms to guarantee it never falls below 3.7, and empower our customers to make the necessary decisions.

This will not make us lose our jobs … this will lead to more work, more meaningful work and thus more fun.

So we were right: What an exciting time to be alive!

Where’s the Food? was originally published in Holisticon Consultants on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever-so-often when I build process applications for my customers projects, I am confronted with the same requirement: One the one hand, we want to model complex business logic flows as BPMN files and let camunda control the execution, including asynchronous continuations, external workers, event subscriptions and so on.
On the other hand, from the users perspective, the interaction should feel like a synchronous, wizard like screen flow.

For years, we implemented this behavior using polling and timeouts, as described in this almost 12 year old, but still relevant article: “Page-Flow vs. Process-Flow — how a UI Mediator might help”.

Though this is a working solution that proofed its value, there is quite a lot to consider and implement, both on the web client- and on the process application-side.

So there has to be a better solution. And there is: Register your controller for the desired process state (in the simpliest case: the next user task is created) and retrieve a CompletableFuture in return. Then use a delegate expression listener on an activity to complete the future, thus continuing the synchronous execution of the controller logic and return the desired result.

Take the above BPMN diagram: We want to start a process (by clicking some button for example) and directly start working on the user task, so it feels like we are just navigating through a SPA flow.

But: There is some expensive heavy business logic that has to be executed before the user task is ready to work on. This logic could (as mentioned above) also involve external task workers or message communication between distributed systems. In our simple case here, we just hid a timer that waits for 5 seconds inside a collapsed embedded sub process:

Let’s have a look at the implementation in detail.

Step 1

Start a new process instance and register a CompletableFuture. Instead of a ProcessInstance or its Id , we return this future to the controller.

private val futures = ConcurrentHashMap<BusinessKey, CompletableFuture<TaskId>>()

fun startProcess(businessKey: BusinessKey): CompletableFuture<TaskId> {
  val future = futures.computeIfAbsent(businessKey) { CompletableFuture() }
  runtimeService.startProcessInstanceByMessage(MSG_START, businessKey)
  return future
}

We need a “registry” for the future, so the async process execution can access it later.

Step 2

Use a TaskListener on creation of the UserTask to complete the future:

val onTaskCreation = TaskListener {
  futures.remove(it.execution.businessKey)?.complete(it.id)
}

So no matter how long the process needs to reach the state we are interested in, it will be able to look up the future on the registry, remove it (it has fulfilled its duty) and complete it.

Step 3

In the controller, keep the future and join() to block the controller thread while the process is executing. Then return the creation URI for the task form:

@PostMapping
fun startProcess(@RequestParam businessKey: BusinessKey): ResponseEntity<Unit> {
  val taskId = process.startProcess(businessKey).join()
  return ResponseEntity
    .created(URI.create("/camunda/app/tasklist/default/#/?task=$taskId"))
    .build()
}

And voila: we are done:

Summary

We just saw a simple, effective way to block the controller until we reached a desired state in the process. There was no need to provide a query endpoint for the UserTask and implement a polling or retry loop in the frontend to continue the UI flow. The key element is the future registry, which allows the synchronous controller flow and the asynchronous process flow to share the same CompletableFuture instance and thus notify each other on when something is done.

Discussion

Two things quickly come to mind: First: this mediation relies on an in-memory registry. What if the application fails during execution of business logic, what if the system goes offline, what if we loose the registry or try to re-execute the same instance?
Well, these are always tricky scenarios that have to be discussed carefully, BUT: I strongly believe, that this future based UI mediation does not supply any additional risk here.
Either the business logic before the UserTask fails … then the target state is never reached and you will need to handle the incident, no traditional polling would help you to continue.
Or the business logic is successful, but something with registering/accessing the future went wrong, or you try to access a future that has already been completed … In this case, you still have a persisted defined state in the camunda database and can easily recover by just opening the task in your tasklist to continue.

In any case, it is of course a good idea to define a timeout on future completion, so you do not keep the client waiting forever. Or, even better, consider returning the future directly, so your UI client can wait for the completion. Even switching to webflux/SSE and just pushing the correct state to the client is possible without much additional coding, but that is out of the scope of this example.

As always, you can read the full example source code in my Github-repository, please feel free to play around and provide improvements, or share your thoughts and questions in the comment section.

Back to the Future — Camunda Task UI mediation done right was originally published in Holisticon Consultants on Medium, where people are continuing the conversation by highlighting and responding to this story.

I assume that if you read this, you are familiar with the camunda platform 7 spring boot solution. And maybe you are running the community (aka FOSS) edition of this wonderful process engine.
Could be because you are just exploring for a pet project, you are still evaluating and have not yet switched to the enterprise edition (which I would still recommend for production usage) or are brave and run your production environment without enterprise support …
Either way, one thing you might possibly be missing is the history plugin. Once your process instance finished it is no longer visible in the camunda cockpit and you have to use the REST or Java API of the history-service to find out what exactly happened during execution.

I recently learned about a community cockpit plugin while chatting at this years CamundaCon in Berlin and finally got the time to explore it.

Open source “history plugin” for Camunda Cockpit

The plugin has been created by Camunda Champion Asko Soukka (aka datakurre) and is available on his github repository. Thanks to the “new“ camunda cockpit system (introduced with camunda 7.14), it just consists of four *.js files that you have to provide to your camunda (spring-boot) application.

I grew up in a time when installing a custom plugin required downloading and unzipping the camunda-webapp war file, modifying its content, repackage it in the correct way and deploy it to a mysterious software component called the JBoss application server. So I was really impressed how easy this has become. Kudos to the camunda team.

Asko did a great job of documenting the plugin features (and how it is not supposed to replace the enterprise plugin nor claims to make an EE subscription obsolete) in his blog post and the github readme.
But using spring boot, I was missing some concrete hints how to install and use it in my camunda CE project. Luckily, he forwards to a camunda forum discussion where this problem has been solved.

Installation in camunda spring boot

To safe you some time, I will document my learnings here. It is really simple:

1. Create a spring boot application and use the camunda spring boot starter.
2. create a the directory `./src/main/resources/META-INF/resources/webjars/camunda/app/cockpit/scripts`
3. Clone the repository or just download the files mentioned in his docs
4. copy those files to the scripts repository
5. run your application

Once you are done, it should look like this:

src/main/resources/
├── META-INF
│   ├── resources
│   │   └── webjars
│   │       └── camunda
│   │           └── app
│   │               └── cockpit
│   │                   └── scripts
│   │                       ├── config.js
│   │                       ├── definition-historic-activities.js
│   │                       ├── instance-historic-activities.js
│   │                       ├── instance-route-history.js
│   │                       └── robot-module.js

Now go to the process instance view of the cockpit and you can switch to the history tab and explore the activites and process variables of your completed instances that otherwise would not be available in the CE cockpit anymore. Nice work!

Using “a” history plugin with spring-boot and camunda platform 7 community edition was originally published in Holisticon Consultants on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reproducible, cross platform builds are key in modern, distributed, CI based development. “It works on my machine” is just not got enough anymore.

This becomes a problem, when you locally build with your own central maven version (let’s say: latest, 3.8.1), while your colleagues still use 3.6.3 and your build server does something completely different.
When the build fails on any of those machines, could it be that the maven versions of the central installation, the configured Java version and the versions of used plugins are incompatible?

The maven wrapper (heavily inspired by the gradle pendant which is part of the gradle build system) addresses this issue. Instead of building with your central installation, each project can define its own specific maven version which is downloaded to your ~/.m2/wrapper/dists directory and executed via the wrapper script mvnw (provided for *ix, mac and windows).

So far, so good. But now you have to remember to execute ./mvnw instead of mvn everytime you build via CLI. This can a) become quite annoying and b) thus be forgotten.

Shell function to the rescue!

To overcome this situation, I have implemented a function (in my case initialized via my zsh setup via $ZSH_HOME/custom/maven.zsh, but you can choose any setup you like best) that when you type mvn in the console either takes the mvnw or the central installation as a fallback.

This script traverses up in the path hierarchy until it finds a mvnw script, if it reaches root (or your defined STOP), it falls back to the central installation.

One note on gitignore

Additional hint: with the latest version of the maven wrapper, you do no longer need to commit a binary jar to your repo, it automatically downloads the jar for you via a Java helper. So it is good practice to include this snippet in your .gitignore file when working with the wrapper:

# https://github.com/takari/maven-wrapper#usage-without-binary-jar
.mvn/wrapper/maven-wrapper.jar

For example, consider I received a command:

data class WithdrawMoney(
  val accountId: String,
  val amount: Amount
) {
  data class Amount(val value:BigDecimal, val currency: Currency)
}

and want to emit an event:

data class MoneyWithdrawn(
  val accountId: String,
  val amount: Amount
) {
  data class Amount(val value:BigDecimal, val currency: Currency)
}

So I will have to implement a manual copy function that creates the event based on the command:

fun WithdrawMoney.createEvent() = MoneyWithdrawn(
  accountId = this.accountId,
  amount = Amount(
    value = this.amount.value,
    currency = this.amount.currency
  )
)

which, as you can imagine will become a tedious, repetitive and thus error prone task if the number of fields and subtypes increases.

So I went looking for a mapping tool like mapstruct or model-mapper that I can use with data classes in kotlin. But currently, those do not support kotlin to an extend that would satisfy my needs. To get them working properly, one would either have to make fields in data classes mutable and nullable (which contradicts the reasons that made me choose kotlin data classes for commands and events in the first place) or add a lot of manual code to the mapper tool, which questions the choice of a framework at all.

Luckily, kotlin provides kotlin-reflect which allows us to call the primary data class constructor as a map of properties. So with the help of this very cool discussion on stackoverflow and another great baeldung blog article, I came up with this DataClassMapper class that works with reflection only and requires no additional frameworks:

// (1) import kotlin-reflect extension functions
import kotlin.reflect.*
import kotlin.reflect.full.*

// (2) define alias for Mapper function
typealias Mapper<I, O> = (I) -> O

/**
 * Mapper that can convert one data class into another data class.
 *
 * @param <I> inType (convert from)
 * @param <O> outType (convert to)
 */
// (3) class that gets input and output class and implements Mapper   (-> 2)
class DataClassMapper<I : Any, O : Any>(
    private val inType: KClass<I>, 
    private val outType: KClass<O>
) : Mapper<I, O> {

  companion object {
    // (4) provide reified constructor that does not require passing of KClass attributes
    inline operator fun <reified I : Any, reified O : Any> invoke() = DataClassMapper(I::class, O::class)

    fun <I : Any, O : Any> setMapper(mapper: Mapper<I, O>) = object : Mapper<Set<I>, Set<O>> {
      override fun invoke(data: Set<I>): Set<O> = 
            data.map(mapper).toSet()
}
  }

  // (5) get constructor of target data class
  private val outConstructor = outType.primaryConstructor!!
  // (6) get properties from input type (lazily)
  private val inPropertiesByName by lazy { inType.memberProperties.associateBy { it.name } }

  // (8) get value of source data via reflection or call registered converter
  private fun argFor(parameter: KParameter, data: I): Any? {
    // get value from input data ...
    val value = inPropertiesByName[parameter.name]?.get(data) ?: return null

    // if a special mapper is registered, use it, otherwise keep value
    return fieldMappers[parameter.name]?.invoke(value) ?: value
  }

  // (7) call the target constructor with a map of source attributes and values, where argFor defines the value to use (see (8)
  override fun invoke(data: I): O = with(outConstructor) {
    callBy(parameters.associateWith { argFor(it, data) })
  }

  // (9) register converter classes on attribute level to support transitive conversions or collection types
  val fieldMappers = mutableMapOf<String, Mapper<Any, Any>>()
  inline fun <reified S : Any, reified T : Any> register(parameterName: String, crossinline mapper: Mapper<S, T>): DataClassMapper<I, O> = apply {
    // to be able to store the sub-mappers, we have to wrap them as (Any) -> Any
    this.fieldMappers[parameterName] = object : Mapper<Any, Any> {
      override fun invoke(data: Any): Any = mapper.invoke(data as S)
    }
  }

}

Using this class, you can now define mappers for each (sub-)type and provide composition of mappers for complex data structures like this:

// sub mapper for Amount (using the reified constructor (4))
val amountMapper = DataClassMapper<WithdrawMoney.Amount, MoneyWithdrawn.Amount>()

// mapper from command to event using the amountMapper
val commandMapper = DataClassMapper<WithdrawMoney, MoneyWithdrawn>()
  .register("amount", amountMapper)

// actual creation of event based on command types 
val event = commandMapper(command)

The DataClassMapper is available on my github repository. If this proves to be useful, I will publish a mapper-lib on jcenter, but so far, just copy it to your project and start exploring and giving feedback.

Kotlin Data Class mapping was originally published in Holisticon Consultants on Medium, where people are continuing the conversation by highlighting and responding to this story.

Foo exposes two read only properties ‘eager’ and ‘lazy’ which both are backed by the private ‘count()’ function.

If you access ‘eager’, you always get a new increased value of count, if you access ‘lazy’, it will increase count once and afterwards forever keep that value:

lazy: 1
lazy: 1
eager: 2
eager: 3
lazy: 1

You can also use these as extension vals on existing classes …