[ 
https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17461972#comment-17461972
 ] 

ASF subversion and git services commented on LUCENE-10255:
----------------------------------------------------------

Commit 7e1f3fef699376cc6069a31a5498670080741e98 in lucene's branch 
refs/heads/branch_9x from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene.git;h=7e1f3fe ]

LUCENE-10255: add unsynced providers to the module.


> 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
>            Assignee: Dawid Weiss
>            Priority: Major
>         Attachments: screenshot-1.png, screenshot-2.png
>
>          Time Spent: 36h 10m
>  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-
> https://github.com/dweiss/lucene/tree/jms2
> 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.- (not true)
> * 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).- (with separate module 
> and classpath configurations there is a possibility to verify the 
> consistency).
> * 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).
> * We will have to rethink the long-term strategy of how white-box tests work. 
> There are some guidelines here but all of them have some cons (IDEs being 
> confused). 
> https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular
> * it's pretty much impossible to exclude transitive dependencies from modules 
> we depend on - if they're not compile-time only (static) requirements, they 
> will have to be present on module path.
> * supporting modules may or may not work in your IDE.



--
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

Reply via email to