Philipp Ossler
Philipp Ossler
**Description** Write a guide for developers to cover: * bootstrapping the engine * SPIs * configuration Could be similar to https://camunda.github.io/feel-scala/docs/reference/developer-guide/developer-guide-introduction blocked by #112
**Description** Currently, the project doesn't have proper documentation. There is only the README with some basic information. Since the project will be used by two other Camunda projects, we should...
**Description** Add a contribution guide to the project. This could look similar to https://github.com/camunda/feel-scala/blob/master/CONTRIBUTING.md
**Description** Check the current issue labels. Align with the labels of the [FEEL-Scala](https://github.com/camunda/feel-scala/labels) project.
**Description** Update the current issue templates. Create a template for pull requests.
**Description** Since the DMN engine will be integrated into Java projects, it should expose the same APIs for Scala and Java. The (major) public classes should be used smoothly with...
**Description** Currently, we need to pass the variables for the evaluation as a map. The FEEL engine exposes an API to pass a context instead. The context allows fetching the...
**Description** In a decision literal expression, we can define the expected types for [result value](https://docs.camunda.org/manual/7.16/reference/dmn/decision-literal-expression/#variable-type-definition). We should check if the value matches the given type. The evaluation should fail if...
**Description** In a decision table, we can define the expected types for * the [input values](https://docs.camunda.org/manual/7.16/reference/dmn/decision-table/input/#input-type-definition) * the [output values](https://docs.camunda.org/manual/7.16/reference/dmn/decision-table/output/#output-type-definition) We should check if the values match the given types....
I can invoke a function that is defined in a required BKM. The function can be defined * as a function definition (as decision logic) * as a literal in...