You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The cause is Gradle's decision to put api and impl in the class path instead of the module path.
Gradle seems to make this decision based on the fact that app is not a module.
This decision breaks the service loader mechanism. impl declares it's provided services in its module definition.
It is meant to be put in the module path, not the class path.
One may be tempted to avoid this problem by redeclaring impl 's services in META-INF/services.
This way, when impl be put in the class path, the service loader is satisfied.
However, api module designers intended for the spi package to have restricted access to impl only.
Allowing api and impl in the class path makes this restriction meaningless.
To enforce this restriction, api and impl must require the module path.
This is just a contrived example.
In the real case I was working with, there should be a closed set of N providers for a certain service.
The user must not be able to insert providers in that set.
Currently, one cannot apply this kind of architecture with non-modular Gradle applications.
The text was updated successfully, but these errors were encountered:
The issue is in the backlog of the relevant team but the existence of a workaround makes it non-critical so it might take a while before a fix is made.
You might be able to tell Gradle to infer module path by calling java.modularity.inferModulePath = true (call set for Kotlin DSL without assignment operator)
This simple project should respond to
./gradlew run
withHello World!
.Instead, it raises
NoSuchElementException
.https://github.com/pedrolamarao/gradle-module-path-decision
The cause is Gradle's decision to put
api
andimpl
in the class path instead of the module path.Gradle seems to make this decision based on the fact that
app
is not a module.This decision breaks the service loader mechanism.
impl
declares it's provided services in its module definition.It is meant to be put in the module path, not the class path.
One may be tempted to avoid this problem by redeclaring
impl
's services inMETA-INF/services
.This way, when
impl
be put in the class path, the service loader is satisfied.However,
api
module designers intended for thespi
package to have restricted access toimpl
only.Allowing
api
andimpl
in the class path makes this restriction meaningless.To enforce this restriction,
api
andimpl
must require the module path.This is just a contrived example.
In the real case I was working with, there should be a closed set of N providers for a certain service.
The user must not be able to insert providers in that set.
Currently, one cannot apply this kind of architecture with non-modular Gradle applications.
The text was updated successfully, but these errors were encountered: