[
https://issues.apache.org/jira/browse/LUCENE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453632#comment-17453632
]
Dawid Weiss commented on LUCENE-10286:
--------------------------------------
I've pushed a commit to https://github.com/dweiss/lucene/tree/jms which shows a
proof of concept of how this can be done. Essentially I resigned from using
gradle's built-in mechanism of handling modular paths since it's just not
flexible enough. Instead, I opted for explicit declarations of modular
dependencies on configurations analogous to gradle's java plugin (api,
implementation, etc.) but with a "Module" suffix. Dependencies declared on
these configurations will end up on modular path instead of the classpath. For
example, this is morfologik's gradle build descriptor:
{code}
dependencies {
apiModule project(':lucene:core')
apiModule project(':lucene:analysis:common')
apiModule 'org.carrot2:morfologik-stemming'
implementationModule 'org.carrot2:morfologik-polish'
implementationModule 'ua.net.nlp:morfologik-ukrainian-search'
testImplementation project(':lucene:test-framework')
}
{code}
The "ua.net.nlp:morfologik-ukrainian-search" dependency is an automatic module
with the name derived from the jar file so the module-info becomes:
{code}
module org.apache.lucene.analysis.morfologik {
...
requires morfologik.ukrainian.search;
...
{code}
which may not look pretty but is the default mechanism of promoting JARs to
automatic modules provided by Java runtime.
The PoC on the branch includes hacks required to make it all work - it's fairly
small and self-contained. We basically turn off gradle's default module finder
and substitute it with our own resolution of classpath vs. module path. The key
element of difficulty was in providing the "old-fashioned" classpath to other
tasks so that nothing breaks. This is achieved with a bit of custom gradle
configuration-extension magic.
I'm not saying it's the best solution out there but it seems to work. I invite
you to suggest a better solution, especially Elasticsearch folks who can
consult gradle experts in their ranks! ;)
> 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
