Skip: The required behavior can be reached by replacing the RuntimeContainerDelegateImpl. But I isolated the step configuration to make overwriting easier. see https://github.com/camunda/camunda-bpm-platform/pull/254

Note: This is mainly an issue for the spring boot extension but might also leed to a more open and flexible configuration system.

Story: As developer, I want to set up and configure a camunda spring boot application without using an additional xml file. It should be enough to just have application.properties|yaml.

What blocks this? When using a ProcessApplication, the RuntimeContainerDelegateImpl takes care of setting up deploymentOperationsSteps. These are hardcoded and not configurable.
Problem is the first step: "ParseProcessesXmlStep". This is able to return a default ProcessesXml instance or read the xml file. But it cannot deal with "no processes.xml but properties".

My first thought was to get inside this step, do some "if/else" config and switch based on ENV properties existing and so on.
But then: it does not feel right.

What I would love to have is to read the required steps form some kind of configuration, so I could just overwrite the ParseProcessesXmlStep with a custom implementation.

What do you think of having a List of DeploymentOperationSteps on the ProcessEngineConfigurationImpl? I could thean just provide my own list of steps and I am done.

Another option would be to have those steps on the processApplication directly, So the AbstractProcessApplication would have a list of steps and my custom Application would overwrite this list.