[
https://issues.apache.org/jira/browse/LUCENE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453633#comment-17453633
]
Dawid Weiss commented on LUCENE-10286:
--------------------------------------
Also, the code contains some remarks about how we could leverage gradle
dependency information to automatically validate the module descriptor; I leave
this for far future but it's certainly doable.
https://github.com/dweiss/lucene/commit/230d5c0d5afbd66564b39681268f9411df2b432f#diff-e95a67573dbd870a71d12e6e101d52707c6bf4d1c0d32855c859ae342138f0dbR26-R39
> 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
> Assignee: Dawid Weiss
> Priority: Major
>
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
