The documentation needs a fix

I’ve spent many hours trying to implement the camunda-spring-boot-starter, by using the following doc as a reference.
http://camunda.github.io/camunda-bpm-spring-boot-starter/docs/current/
And the many hours wasted came about because of a mistake in the documentation.

In section 6.3. Camunda application properties the property .deployment-resource-pattern is placed under the prefix camunda.bpm.job-execution, which is wrong, it belongs under the camunda.bpm prefix.

When trying to edit this value in application.properties with the line camunda.bpm.job-execution.deployment-resource-pattern=some-pattern-value, nothing happens and camunda keeps auto deploying everything as if with the default deployment pattern.
When specified as camunda.bpm.deployment-resource-pattern=some-pattern-value, the custom specified pattern is actually used and starts to function as intended.

FYI. I’m using the following dependecy:
<dependency> <groupId>org.camunda.bpm.extension.springboot</groupId> <artifactId>camunda-bpm-spring-boot-starter</artifactId> <version>2.2.0</version> </dependency>

Best regards, Walter.

2 Likes

Thanks, Walter, I updated the properties section accordingly. Sorry for the inconvenience.

Be advised though that using the spring resource scan is considered to be deprecated, you should check if @EnableProcessApplication and META-INF/processes.xml works as well …

1 Like

Didn’t know about the deprecation. What is the proper way of deploying then? Manually building via the org.camunda.bpm.engine.repository.DeploymentBuilder class? I’m pretty new to Camunda in general, so a lot of these concepts are new to me.

EDIT: Nevermind. Figured out what you meant, and what I had initially missed, regarding using the @EnableProcessApplication and META-INF/processes.xml deployment method. Haven’t tried any code, since I’m already off work, but will definitely try it out tomorrow.

BTW, since we’re on this subject. In the originally discussed documentation, section 6.1. Using the ProcessApplication there is a text that goes This also allows all processes.xml configuration features described here., but the word here isn’t a link. I think it should reference this other documentation regarding processes.xml:
https://docs.camunda.org/manual/7.6/user-guide/process-applications/the-processes-xml-deployment-descriptor/

Thanks, you seem to have a talent to spot documentation flaws … keep it up! Fixed it.

You just have to provide an empty file under src/main/resources/META-INF/processes.xml and use the @EnableProcessApplication annotation on your SpringBootApplication.

Camunda scans for the processes file, detects it and then scans for all relevant models in your resources folder, just like the deployment-pattern-scan would. But: camunda also registers the deployments to the engine/application, allowing you to be deployment-aware (run two nodes against one datasource, one node only caring about process-a, the other about process-b). Plus, using the processes.xml is the only way to register embedded forms to the webcontext, meaning with the autodeployment via resource pattern, you are not able to use forms.
This has been causing a lot of confusion in the past, thats why we agreed to disable supporting this with the next major release. It would be ok for now to do so, but if you are starting fresh: do it right.
Setup of processApplication/processEngine and deployment via processes.xml does not differ wth spring boot from the documentation you already linked.

1 Like

Tried out the proper @EnableProcessApplication and META-INF/processes.xml

Works quite well out of the box (with empty/default processes.xml values). Not a fan of how it bumps up the version of all my process definitions, when only one .bpmn is changed in the deployed .war, but I’m guessing it’s a matter of properly configuring versioning settings and the processes.xml.

Still, works much better than the SpringAutoDeployment, which bumped up all my processes definitions on every .war redeployment (even when the contained .bpmn was the same).

EDIT: Found the property I was looking for isDeployChangedOnly. And yes I paid attention to the Note about how it is not advised and needs to be handled with care, regarding bound resources in a deployment.