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;
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;
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"
, 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.
The "implementation", on the other hand, will handle both configuration (at compile time and runtime config)