Whether we do this, is something we have to decide before 7.2.0-Final.
- The engine itself actively looks for the Spin module in its classpath => Tight integration of engine and Spin
- Spin is a process engine plugin and its activation can be configured in the process engine configuration
- Going with the alternative means that there is no glue code required in the engine to integrate Spin
- Going with the alternative means we have to create a "spin-engine-plugin" project and furthermore move all Spin-related engine classes and tests to that project
From an end user's perspective, there is no difference in behavior. However, with the alternative, there has to be a registration configuration with the engine (unless we also improve the plugin lookup mechanism).
The alternative solution is cleaner, however requires some effort. Changing this after 7.2.0-Final could not be so easy, since the alternative might require an explicit registration which is a change we cannot demand from users after the release.
- Spin registers variable serializers/function mappers/script resolver on engine startup from ProcessEnginePlugin
- migrate all Spin-related tests to Spin
- add new maven project in Spin repo that provides this integration
- extract XmlDomDataformat and JsonJacksonDataFormat into separate maven projects
- add spin bom project
- configure plugin in all distros and standalone webapps
- document plugin usage and configuration