-
Bug Report
-
Resolution: Fixed
-
L3 - Default
-
7.13.1, 7.14.0-alpha1
Problem
- The camunda-engine-feel-scala artifact contains the classes of org.camunda.feel:feel-engine
- When using the Standalone FEEL Engine together with the DMN Engine, the classes are overlapping, which could lead to unexpected behavior
Solution
- A new artifact of the FEEL Engine is published, which already shades the Scala Library
- The shaded FEEL Engine artifact is included in Camunda BPM distros by default
- The DMN Engine cannot be reconfigured to use the unshaded FEEL Engine artifact, which means that calling the API directly results in handling prefixed Scala Library classes, e.g., camundajar.impl.scala.Either; this can be avoided by using the FEEL Engine as Java Script Engine (JSR 223)
Reasoning
An anti-solution would be to relocate the FEEL Engine in the camunda-engine-feel-scala artifact:
- The package name of the FEEL Engine would suddenly change
- This would be surprising for 7.13 users who already implemented code against the FEEL Engine classes (e.g., org.camunda.feel.syntaxtree.ZonedTime)
Hints
- Add documentation here: https://docs.camunda.org/manual/7.13/update/patch-level/#special-considerations
- The Maven coordinates of the FEEL Engine shouldn't change
- To be discussed: Introduce either a classifier like scala-shaded or a new artifact id
This is the controller panel for Smart Panels app
[CAM-12136] Standalone FEEL Engine cannot be used together with the DMN Engine
| Mentioned Roles |
| Mentioned Groups |
| Description |
Original:
*Problem*
* The {{camunda-engine-feel-scala}} artifact contain the classes of {{org.camunda.feel:feel-engine}} * The Scala Library is shaded to the package name {{camundajar.impl.scala}} * When using the Standalone FEEL Engine together with the DMN Engine, the classes are overlapping which could lead to unexpected behavior *Solution* * A new artifact of the FEEL Engine is published which already shades the Scala Library * The shaded FEEL Engine artifact is included in Camunda BPM distros by default *Reasoning* * Users are not forced to use a specific version of the Scala Library in their projects * An anti-solution is to relocate the FEEL Engine in the {{camunda-engine-feel-scala}} artifact ** The package name of the FEEL Engine would suddenly change ** This would be surprising for 7.13 users which already implemented against the FEEL Engine classes (e.g., against {{org.camunda.feel.syntaxtree.ZonedTime}}) * Users which use the standalone FEEL Engine can use the not shaded artifact ** Users would need to take care themselves to have the compatible Scala Library on the classpath *Hints* * Add documentation here: https://docs.camunda.org/manual/7.13/update/patch-level/#special-considerations * The maven coordinates of the FEEL Engine shouldn't change by default, instead, introduce a new artifact with a new artifact id (e.g., {{feel-engine-scala-shaded}} |
New:
*Problem*
* The {{camunda-engine-feel-scala}} artifact contains the classes of {{org.camunda.feel:feel-engine}} * The Scala Library is shaded to the package name {{camundajar.impl.scala}} * When using the Standalone FEEL Engine together with the DMN Engine, the classes are overlapping which could lead to unexpected behavior *Solution* * A new artifact of the FEEL Engine is published which already shades the Scala Library * The shaded FEEL Engine artifact is included in Camunda BPM distros by default *Reasoning* * Users are not forced to use a specific version of the Scala Library in their projects * An anti-solution is to relocate the FEEL Engine in the {{camunda-engine-feel-scala}} artifact ** The package name of the FEEL Engine would suddenly change ** This would be surprising for 7.13 users who already implemented against the FEEL Engine classes (e.g., against {{org.camunda.feel.syntaxtree.ZonedTime}}) * Users who use the standalone FEEL Engine can use the not shaded artifact ** Users themselves would need to take care to have the compatible Scala Library on the classpath *Hints* * Add documentation here: [https://docs.camunda.org/manual/7.13/update/patch-level/#special-considerations] * The maven coordinates of the FEEL Engine shouldn't change by default, instead, introduce a new artifact with a new artifact id (e.g., {{feel-engine-scala-shaded}} |
| Mentioned Roles |
| Mentioned Groups |
| Description |
Original:
*Problem*
* The {{camunda-engine-feel-scala}} artifact contains the classes of {{org.camunda.feel:feel-engine}} * The Scala Library is shaded to the package name {{camundajar.impl.scala}} * When using the Standalone FEEL Engine together with the DMN Engine, the classes are overlapping which could lead to unexpected behavior *Solution* * A new artifact of the FEEL Engine is published which already shades the Scala Library * The shaded FEEL Engine artifact is included in Camunda BPM distros by default *Reasoning* * Users are not forced to use a specific version of the Scala Library in their projects * An anti-solution is to relocate the FEEL Engine in the {{camunda-engine-feel-scala}} artifact ** The package name of the FEEL Engine would suddenly change ** This would be surprising for 7.13 users who already implemented against the FEEL Engine classes (e.g., against {{org.camunda.feel.syntaxtree.ZonedTime}}) * Users who use the standalone FEEL Engine can use the not shaded artifact ** Users themselves would need to take care to have the compatible Scala Library on the classpath *Hints* * Add documentation here: [https://docs.camunda.org/manual/7.13/update/patch-level/#special-considerations] * The maven coordinates of the FEEL Engine shouldn't change by default, instead, introduce a new artifact with a new artifact id (e.g., {{feel-engine-scala-shaded}} |
New:
*Problem*
* The {{camunda-engine-feel-scala}} artifact contains the classes of {{org.camunda.feel:feel-engine}} * The Scala Library is shaded to the package name {{camundajar.impl.scala}} * When using the Standalone FEEL Engine together with the DMN Engine, the classes are overlapping which could lead to unexpected behavior *Solution* * A new artifact of the FEEL Engine is published which already shades the Scala Library * The shaded FEEL Engine artifact is included in Camunda BPM distros by default *Reasoning* * Users who use the standalone FEEL Engine can use the not shaded artifact ** Users themselves would need to take care to have the compatible Scala Library on the classpath * By default, users are not forced to use a specific version of the Scala Library in their projects * An anti-solution would be to relocate the FEEL Engine in the {{camunda-engine-feel-scala}} artifact ** The package name of the FEEL Engine would suddenly change ** This would be surprising for 7.13 users who already implemented code against the FEEL Engine classes (e.g., {{org.camunda.feel.syntaxtree.ZonedTime}}) *Hints* * Add documentation here: [https://docs.camunda.org/manual/7.13/update/patch-level/#special-considerations] * The maven coordinates of the FEEL Engine shouldn't change, instead, introduce a new artifact with a new artifact id (e.g., {{feel-engine-scala-shaded}} |
| Mentioned Roles |
| Mentioned Groups |
| Labels | New: SUPPORT |