Dawid Weiss created LUCENE-10286:
------------------------------------
Summary: Module path to dependencies that are not automatic
modules (according to gradle)
Key: LUCENE-10286
URL: https://issues.apache.org/jira/browse/LUCENE-10286
Project: Lucene - Core
Issue Type: Sub-task
Reporter: Dawid Weiss
So... the workaround [~tomoko] came up with here:
https://github.com/dweiss/lucene/pull/8/files will not work. Basically, the
workaround is to force gradle's compile java task to use module path with the
classpath entries:
{code}
plugins.withType(JavaPlugin) {
tasks.withType(JavaCompile) {
doFirst {
options.compilerArgs += [
"--module-path", classpath.asPath
]
{code}
this is indeed quoted as a solution all over the place but it predates what
Gradle currently does (module path inference).
There are multiple problems with the above:
1) java compilation task does not "understand" that we pass a module path
argument and happily issues its own version from the inferred path - I
confirmed this by looking at the logs. The second option pretty much takes
precedence (javac doesn't complain, it just takes the value of the last option)
and things may break in weird ways there.
2) the solution is also flowed because classpath can contain directories that
are not modules... think cross-project dependencies (to other projects that are
not modules). These directories would not be converted to automatic modules and
would in fact fail the compilation.
I looked at gradle source code and the "module inference" is pretty much
non-configurable - it's what the docs say (automatic module name or proper
module descriptor). Anything else is treated as a classpath entry, with no way
of moving it to module path. There is an open issue that touches on this
subject here:
https://github.com/gradle/gradle/issues/12630
and Jendrik Johannes of Gradle published a plugin leveraging Gradle's "artifact
transforms" that allow you to create full module info for jars that are missing
it:
https://github.com/jjohannes/extra-java-module-info#how-to-use-this-plugin
As fancy as this solution is... I don't like it that much. It's what Java
already does for you (conversion of jars to automatic modules) - I'd rather
rely on built-in mechanisms than gradle magic.
The only way out of this that I currently see is to turn off automatic module
inference for these projects that contain non-modular dependencies and manually
modify the classpath + module path for tasks that may be using them (primarily
javac). I'm pretty sure it can be done with relative ease but I don't have any
more time today to provide a proof of concept that would do it for one of the
subprojects. Will do it tomorrow, hopefully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
