While trying to find a solution to what I lovingly call Gradle's
„Anti-JPMS“ issue [1], I discovered that even if that one particular
issue is worked around, Gradle then, frustratingly, presents yet another
hurdle to developing with the JPMS! Specifically, it co-opts the
META-INF/services mechanism to bundle a non-JAR file-spec-compliant
services configuration file.
That technically-inappropriate
META-INF/services/org.codehaus.groovy.runtime.ExtensionModule entry in
Gradle's gradle-api-{version}.jar file is used by Gradle to extend the
Groovy language; which Gradle relies on. Apparently, that service entry
extends Groovy with Java methods [2].
The contents of that file...
moduleName=model-core
moduleVersion=1.0
extensionClasses=org.gradle.api.internal.provider.MapPropertyExtensions
...breaks Jigsaw when gradle-api-{version}.jar is in the module path
(for Gradle plugin development, say). A Gradle Test Task configured for
JPMS modules — as discussed in the Gradle documentation [3] — will
result in Gradle producing a command like this for example:
java --module-path
<$GRADLE_USER_HOME>/.../gradle-api-5.6.2.jar:mymods/foo.jar:...
--patch-module mymod=/path/to/test/classes ...
When Gradle's Test Runner tries to execute that command, this is the
result:
...[QUIET] [system.out] Error occurred during initialization of boot
layer
...[QUIET] [system.out] java.lang.module.FindException: Unable to
derive module descriptor for
{$GRADLE_USER_HOME}/caches/5.6.2/generated-gradle-jars/gradle-api-5.6.2.jar
...[QUIET] [system.out] Caused by:
java.lang.module.InvalidModuleDescriptorException: Provider class
moduleName=model-core not in module
@AlanBateman? Please can you suggest what can be done to work around
Gradle's moduleName=model-core „anti-JPMS“ blocker?
Thanks in advance.
----
[1] http://bit.ly/antiJPMS
[2] http://bit.ly/CoOptSvcMech
[3] http://bit.ly/BldJ9Guide
