The issues were caused by a lack of specification in our build tool/dependencies script's configuration, which we need to add/configure via "runtimeOnly" or "implementation," So then we can tell our build tool that before running/executing or building, we need to first add those dependencies, in this case the "provider-mod" project or artifact must be specified in the build script dependencies configuration to explicitly inform the build tool that it exist; see the code/syntax below;
driver-mod/build.gradle.kts
dependencies {
implementation(project(":service-mod"))
runtimeOnly(project(":provider-mod"))
}
Why? : use "runtimeOnly" config, because the consumer/"driver-mod" doesn't need "provider-mod" at compile time or we don't want to create an instance/object of it inside of the consumer codes and also the "provider-mod" does not
exports anything, hence why do we need to compile it, but we do need it at runtime because we require an artifact/jar of "provider-mod", the build tool will produce it as we run our project that how the gradle build tool works, there's an hierarchical execution;
Important: don't forget to include the following syntax at the same or consumer build script, as shown below:
This will notify/configure your build tool (gradle) and inform java/JVM, if any of your artifacts/project has/was
"named-module",
"automatic-module", or has a filename
"module-info.class" then it will put/contained/inferred it to as a java named-module configuration. (basically it will put it to the
"—module-path"), so that it will will do the correct execution, it will do the JPMS features. If we do not do this, it will by default insert it at the
"classpath" container/thing, and then the Service Provider features or any JPMS features that must be inside of a
"—module-path" will not work as expected to be.
driver-mod/build.gradle.kts
...
java {
this.modularity.inferModulePath.set(true);
}
...
The "implementation", on the other hand, will handle both configuration (at compile time and runtime config)