[Feature] Make jobrunr JPMS friendly

[duponter]

Is your feature request related to a problem? Please describe.
I am working on a Spring Boot 2.7 Java 17 application.

We are planning a feature where we chose jobrunr as part of the solution. Currently, we are using the jobrunr core and the spring-boot-starter modules.

However, as we are JPMS compliant, there are issues when starting our application using the module path.
As there is absolutely no JPMS related configuration present in jobrunr, our application considers the jobrunr jars as a filename-based automodules and automatically exposes all packages from those jars.

Usually this poses no problem, unless multiple jars expose the same package. This is called 'split packages'.
In case of jobrunr, the core, the jobrunr-spring-boot-starter and the jobrunr_quarkus_extension modules all expose the org.jobrunr.scheduling package. This implies that these modules cannot be used together on the module path.

Describe the solution you'd like
The ideal solution is the introduction of module-info.java in each module. This way JPMS is fully supported and jobrunr can be used both on the module path and the classpath. This also clearly states which packages are exported and therefore are part of the library's api and which packages are considered internal.

This however implies the following changes:

• The source compatibility must be raised to Java 11 (instead of 8).
• Multi Release Jars or an alternative must be provided to keep compatibility with Java 8: https://blog.gradle.org/mrjars
• Each module has its own unique packages to export. Therefore, following classes must be moved to another package:
  • org.jobrunr.scheduling.RecurringJobPostProcessor (in jobrunr-spring-boot-starter)
  • org.jobrunr.scheduling.JobRunrRecurringJobRecorder (in jobrunr_quarkus_extension)
  • ... (I might forget some)

Describe alternatives you've considered
An alternative solution is to be aware of JPMS, but not to support it directly. This implies the following actions:

• Each module should provide a manifest file with at least an Automatic-Module-Name: < chosen module name > entry to the module's MANIFEST.MF. (http://branchandbound.net/blog/java/2017/12/automatic-module-name/)
• The classes mentioned above must be moved to a unique package as explained earlier.

Additional context
I am willing to provide or to contribute to a PR for the JPMS specific configuration and code, but I am not that familiar with the code to make suggestions about moving packages or to decide which packages to expose and which to keep internal.

[rdehuyss]

Hi @duponter - as this will require some discussion and brain-storming, I think it's best to have a short call on which approach to take. Feel free to reach out via mail so we can arrange this.