Using DMN Engine's Java API without introducing its dependencies

Context

I’m currently looking into a big JSF application which heavily relies on expressions being evaluated for its whole interactivity (links, buttons, panels, … you name it) as those things tend to do.
My intention is to introduce the DMN engine and the dmn.js editor for complex configuration scenarios.

Problem

Declaring the dependency to the dmn engine library (7.4.0) triggers the following exception throughout my whole application, despite the fact that JSF (after version 1.1) allows for those actions to be void:
javax.el.MethodNotFoundException: .../login.xhtml @y,x action="#{loginBean.login}": Return type 'void' of method 'login' in 'class com.my-company.LoginBean' does not match 'class java.lang.Object'

The affected code in my .xhtml template and the named class looks like this:

<p:commandButton id="loginButton" action="#{loginBean.login}" />


@Named public class LoginBean { public void login() {} }

Changing the login() method’s signature to not be void but return anything else (i.e. null in every case), solves this problem but would mean countless hours of manual refactoring and testing throughout the whole application - ignoring the possibility of other side effects.

Question

In what way can I use the DMN Engine’s Java API without introducing all of its dependencies?

Providing the DMN Engine as a separate deployment would be acceptable if necessary.
But what dependency is to be declared on my main project to be able to use classes from the org.camunda.bpm.dmn.engine package?

Or is there another option for separating JUEL (which seems to be the culprit here) from the rest of my application (short from using something like Jigsaw in Java 9)?

Can I even configure JUEL to be more relaxed about the return value of expressions (i.e. assuming to return null if nothing else is defined)?
I stumbled upon the property javax.el.ignoreReturnType but are unsure where/how to set this property to true and whether that would be my solution.

My solution for now is to exclude JUEL’s spi jar (which contains the configuration enforcing JUEL to be used for all EL use cases).

<dependencies>
  <dependency>
    <groupId>org.camunda.bpm.dmn</groupId>
    <artifactId>camunda-engine-dmn</artifactId>
    <exclusions>
      <exclusion>
        <groupId>de.odysseus.juel</groupId>
        <artifactId>juel-spi</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
</dependencies>

It seems to work fine (pending further testing):

  • JSF is happy as it is using its usual (default) EL implementation
  • the DMN Engine is happy as it seems to target the JUEL implementation specifically