Sometimes, users want to build an executable (java -jar *.jar) package of their project (for example to run it in a Docker container) and they don't want to use Quarkus or Spring Boot.

In such case, building an uberjar using the Assembly plugin seems like the best choice but that currently fails because the Assembly plugin requires some extra configuration to build the JAR correctly.

Problem 1: one of optaplanner-core dependencies (jaxb-runtime) is a multi-release JAR. To make that work, the uberjar's MANIFEST.MF needs to contain the Multi-Release: true entry. Assembly plugin doesn't add this entry out of the box. This leads to an obscure problem manifesting on JRE 17 because a 17-compatible class is not being selected from the MRJAR structure. Basically, the missing manifest entry makes the MR structure invisible to the JVM.

Problem 2: Assembly plugin doesn't build the META-INF/services structure correctly (out of the box). ServiceLoader mechanism is now used to load a CS implementation dynamically. That doesn't work if the META-INF/services is not constructed properly.

It seems both problems have an easy fix. Problem 1 can be fixed by adding

<manifestEntries>
  <Multi-Release>true</Multi-Release>
</manifestEntries>

to the Assembly plugin config.

Problem 2 seems to be addressed by using the metaInf-services handler.

If the above is not enough to make an executable JAR using the Assembly plugin, we might need to try the Shade plugin.

A working solution should be documented and tested either as an integration test in the optaplanner repository or in the form of a quickstart.

If we fail to build a working example, users should be discouraged from taking that path and they should be pointed directly to Quarkus.