We couldn't load the project sidebar. Refresh the page to try again.
If the problem persists, contact your Jira admin.

    • Icon: Sub-task Sub-task
    • Resolution: Unresolved
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • scala-dmn
    • None

      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

      1. 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
      2. 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
      3. 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

      See
      https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.6400lour6fnr

        This is the controller panel for Smart Panels app

            Loading...

              • Icon: Sub-task Sub-task
              • Resolution: Unresolved
              • Icon: L3 - Default L3 - Default
              • None
              • None
              • scala-dmn
              • None

                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

                1. 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
                2. 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
                3. 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

                See
                https://docs.google.com/document/d/1fvp2qf75W7VBSFjfHVz3iRN4Ynq349R6qtq3eP62opw/edit#bookmark=id.6400lour6fnr

                  This is the controller panel for Smart Panels app

                        Unassigned Unassigned
                        tobias.metzke Tobias Metzke-Bernstein
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        2 Start watching this issue

                          Created:
                          Updated:

                              Unassigned Unassigned
                              tobias.metzke Tobias Metzke-Bernstein
                              Votes:
                              0 Vote for this issue
                              Watchers:
                              2 Start watching this issue

                                Created:
                                Updated: