We’ve got feedback from multiple people from the community that they would find a package rename to org.flowable a good and logical step for the Flowable project. This also includes a rename to flowable.cfg.xml and flowable-context.xml for example.
It would be great to get more feedback before a final decision can be made about the package renaming. So please let us know your opinion. For Flowable 5 we think it’s better to stick with the existing package name, to reduce any impact on running applications. But we are very interested in your opinion about the Flowable 5 modules as well.
We are in favor of the package being renamed to org.flowable as well. In addition, we would also like to request that classes that contain the word ‘Activiti’ in them, for example ActivitiEventBuilder, be renamed to use ‘Flowable’ as well.
In our case management solution, we have customers who customize their processes. That includes Groovy script tasks, and references to various engine classes.
Upgrading these processes will become difficult and error prone. I’d rather we didn’t have to do this!
If it was decided to do this, a tool which upgrades process definitions (including for running instances) would be very much appreciated.
What about renaming and providing a bridge module (if at all feasible)? A little bit like slf4j does (e.g. log4j-over-slf4j). This would give people time to evolve their codebase while still being able to upgrade to 6?
That would be ideal indeed, but it’s difficult to provide the bridge functionality for all the possible classes. If we would come up with a list of classes then it would be feasible I think. Maybe we should release the RC1 6 candidate and get feedback on which bridge classes are needed.
I’d find it a bit awkward to start fresh with Flowable 6 and find packages that reference org.activiti… would be confusing imho.
And with some decent refactoring support, I’d not see a problem with migrating existing projects, or am I missing something?
I just updated to the latest flowable 6 jars and noticed there are still some classes that use the “Activiti” term in the class name. For example: org.flowable.engine.impl.delegate.event.ActivitiEngineEntityEvent. Will there be an additional update to remove the ‘Activiti’ term from all the remaining classes? Also, it appears the extension namespace has not been renamed from “activiti” to “flowable”. Are there any plans to update it as well?
The refactoring was a lot of work and there might still be some classes with an Activiti reference left. The goal is to replace this all with Flowable. Using the flowable namespace could be a good thing to do as well, but this also means that our tooling should generate the flowable namespace, and the embedded Activiti 5 engine should still have support for the activiti namespace as well for backwards compatibility reasons. Right now the xml converter project is shared between version 5 and 6, so this means that also the 6 engine would still support the activiti namespace. I’m not yet sure how we could best support both namespaces. Do you have an idea?
Could it be as simple as updating the parser classes to attempt to read from both namespaces and the converter/export classes to always write to the flowable namespace? A few small tweaks are also needed in the BpmnXmlUtil and BpmnDeployer classes.
would be confusing imho.