Details
-
Sub-task
-
Resolution: Unresolved
-
L3 - Default
-
None
-
None
-
None
Description
AT
Ensure standalone versioning and avoid dependency cycles (Model API, Scala Engine, Engine Platform)
Reasoning
The Scala DMN engine uses the DMN model API to cache the DMN XML description in an in-memory structure. The Scala DMN engine will an upstream project of the Process Engine with a separate versioning. In order to allow for independent releases of the Scala DMN engine, the DMN (and therefore also the XML) model API needs to be released independently from Camunda BPM Runtime as well.
See also the aspired module overview at: https://docs.google.com/drawings/d/1iFHncT9xiZPVJCu1lgzjnGCVGTIlY1dNYiFGCWnLh00/edit?usp=sharing
Scoping
- Minimum: XML & DMN Model API must be relocated
- Pro: only the modules of shared interest are in a separate project
- Con: Inconsistent versions are confusing (7.15.0 vs. 4.4.1)
- Maximum: All Model APIs are relocated
Implementation ideas
- Move DMN Model API to Scala Engine project
- Pros: Progress to DMN will be made in that project in the future, so model and its consumer would be released together; both are upstream projects for the platform => only one additional upstream repo; both are built with Maven
- Cons: is currently a Scala-only project and Model API is Java; XML API needs to be relocated as well, does not natively fit the project scope
- Make DMN Model API a dedicated project/repo
- Pros: native separation of concerns approach (project chain: Model APIs -> Scala DMN -> Platform); most coherent change
- Cons: Yet another repository
- Keep DMN Model API in the platform
- Cons: complicates the Release Build for the platform (building only parts of the platform occasionally); Scala DMN release directly bound to the platform release (must wait for a release of the Model API in the platform), other teams are dependent of the Camunda BPM team when a change makes changing the Model API necessary