[
https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450762#comment-17450762
]
Uwe Schindler commented on LUCENE-10255:
----------------------------------------
Thanks [~sor] for confirmation.
We now have the following names generated from the gradle build:
{noformat}
> Task :showModuleNames
lucene-benchmark-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.benchmark
lucene-backward-codecs-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.backward_codecs
lucene-classification-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.classification
lucene-codecs-10.0.0-SNAPSHOT.jar -> org.apache.lucene.codecs
lucene-core-10.0.0-SNAPSHOT.jar -> org.apache.lucene.core
lucene-demo-10.0.0-SNAPSHOT.jar -> org.apache.lucene.demo
lucene-expressions-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.expressions
lucene-facet-10.0.0-SNAPSHOT.jar -> org.apache.lucene.facet
lucene-grouping-10.0.0-SNAPSHOT.jar -> org.apache.lucene.grouping
lucene-highlighter-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.highlighter
lucene-join-10.0.0-SNAPSHOT.jar -> org.apache.lucene.join
lucene-luke-10.0.0-SNAPSHOT.jar -> org.apache.lucene.luke
lucene-memory-10.0.0-SNAPSHOT.jar -> org.apache.lucene.memory
lucene-misc-10.0.0-SNAPSHOT.jar -> org.apache.lucene.misc
lucene-monitor-10.0.0-SNAPSHOT.jar -> org.apache.lucene.monitor
lucene-queries-10.0.0-SNAPSHOT.jar -> org.apache.lucene.queries
lucene-queryparser-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.queryparser
lucene-replicator-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.replicator
lucene-sandbox-10.0.0-SNAPSHOT.jar -> org.apache.lucene.sandbox
lucene-spatial-extras-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.spatial_extras
lucene-spatial3d-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.spatial3d
lucene-suggest-10.0.0-SNAPSHOT.jar -> org.apache.lucene.suggest
lucene-test-framework-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.test_framework
lucene-analysis-common-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.common
lucene-analysis-icu-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.icu
lucene-analysis-kuromoji-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.kuromoji
lucene-analysis-morfologik-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.morfologik
lucene-analysis-nori-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.nori
lucene-analysis-opennlp-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.opennlp
lucene-analysis-phonetic-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.phonetic
lucene-analysis-smartcn-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.smartcn
lucene-analysis-stempel-10.0.0-SNAPSHOT.jar ->
org.apache.lucene.analysis.stempel
{noformat}
(see https://github.com/apache/lucene/pull/487)
At the moment it is automatic module names, but this issue is about fully
modularizing.
> Fully embrace the java module system
> ------------------------------------
>
> Key: LUCENE-10255
> URL: https://issues.apache.org/jira/browse/LUCENE-10255
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Dawid Weiss
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> I've experimented a bit trying to move the code to the JMS. It is
> _surprisingly difficult_... A PoC that almost passes all checks is here:
> https://github.com/dweiss/lucene/tree/jms
> Here are my conclusions so far:
> * The JMS and gradle add a lot of complexity (this applies to any
> higher-level tooling, including IDEs, I think). For starters, modules have to
> be JARs. The effect of this is that what was previously a set of directories
> from dependencies now has to be a JAR. What was previously an incremental
> update of a single .class file now ripples throughout the build recreating
> module JARs (ZIPs!)... I didn't realize it at first, but it's a costly thing
> to do. I'm not even sure how IDEs handle this issue.
> * A Java module contains metadata (such as the module version or main class)
> that is completely detached from any source file. These things live in a
> class bytecode of the compiled module-info; interestingly, there is no
> source-level way to specify it - these class attributes are injected by the
> 'jar' tool. Gradle has some fancy on-the-fly asm conversion filter that
> injects it.
> * Dependencies between modules will effectively live in two places: in gradle
> build files and in module-info files. And they can go out of sync, although
> it's probably easy to catch (since javac would complain about missing classes
> during compilation, even if they're in module path).
> * Probably the biggest challenge (not covered in the PoC) are with our custom
> javadoc and ecj linter tasks - they see the module-info.java and can't cope
> with it. At the same time, there is no easy way to exclude that one
> particular file: ecj would have to accept a full set of sources (command
> argument limit will be a problem), javac can accept a full set of java
> sources (external file) but then it doesn't copy doc-files properly anymore
> (this is probably easier to fix).
> * There are differences at runtime that are hard to anticipate - for example
> resource lookups via class loader no longer work (I fixed this in Luke).
> After poking a bit and trying it out I have to say I have mixed feelings
> about moving to the JMS. On the one hand, many things are great - the module
> path, module descriptors and access modes. On the other hand, the tooling
> tricks required to make it all work make you shiver.
> If anybody wants to play/ improve things on that experimental branch (I
> converted Luke to a full module - it works), please be my guest. I have to
> sit on this and think whether it's something I really like or not.
--
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
