Whether we do this, is something we have to decide before 7.2.0-Final.

Current behavior:

• The engine itself actively looks for the Spin module in its classpath => Tight integration of engine and Spin

Alternative:

• Spin is a process engine plugin and its activation can be configured in the process engine configuration

Implications:

• 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.

AT:

• 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