I am migrating my grails app from activiti to camunda (both used as grails plugins). Because there is no full (automatic) database migration, I have to do some changes by myself (with the db migration plugin). Only a few new tables will be created by camunda (if the property cmmn is set to true).
To do so I have to disable the job executor from camunda and disable cmmn (to avoid the migration). If I don't disable both mentioned properties, camunda is trying to create the new tables before the database migration plugin can do its part. And this will fail, because some columns are missing (used as foreign key constraints).
After the migration is done by the database migration plugin, the remaining tables should be created by camunda. And this is only done, if cmmn is enabled. So I enabled the job executor in bootstrap.groovy and enabled cmmn.
// will be injected by spring
def processEngine
processEngine.jobExecutor.start()
processEngine.processEngineConfiguration.cmmnEnabled = true
The problem now is, that I am not able to trigger the database table creation. Because this is done during process engine creation / instantiation (and I already have a process engine). The necessary method to call is executeSchemaOperations(), but this method is protected (yes, I know that this isn't really a problem in groovy because private / protected methods can be called). But, and this is my question, is there a better way to trigger the table creation?
I am using grails 2.3.11 and camunda plugin 0.4 (with camunda 7.2).
Best regards and thanks for your help, Daniel
Interesting problem and it seems you have already solved the majority of the problems.
Looking at the executeSchemaOperations() protected method, it appears as though it simply calls a command executor that is retrieved from the process Engine configuration.
So, likely you could do something like:
processEngineConfiguration.getCommandExecutorSchemaOperations().execute(new SchemaOperationsProcessEngineBuild())
SchemaOperationsProcessEngineBuild should be imported from org.comunda.bpm.engine.impl
Obviously, as you say, you could simply call the protected method, but the above gets you past the issue of protected methods.
Cheers, Greg