rdehuyss
commented
2 years ago 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.
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_quarkusextension 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:
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:
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.