[
https://issues.apache.org/jira/browse/LUCENE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450583#comment-17450583
]
Uwe Schindler edited comment on LUCENE-10255 at 11/29/21, 4:50 PM:
-------------------------------------------------------------------
Hi,
please have an overview on Maven central and the good work done by
[~sormu...@gmx.de]:
This table has module names and their artifact names extracted by a script from
Maven central:
https://github.com/sormuras/modules/blob/main/doc/Top1000-2020.txt.md (see also
the repo: https://github.com/sormuras/modules)
When looking at the Top 1000, you will se that all module names that can be
found on Maven Central use the package names / coordinate names. If you read
the JLS, they recommend for packages and modules only "simple names" for small
projects without large outreach.
Here is conclusion what he recommends:
https://sormuras.github.io/blog/2019-08-04-maven-coordinates-and-java-module-names.html
So I just repeat myself: Module names should really be unqiue. I don't care
about 9.0, because its not officially announced, but when we enable the module
system we should use unique names.
Or should we rename also all packages in Lucene's source code and strip off
"org.apache."?
was (Author: thetaphi):
Hi,
please have an overview on Maven central and the good work done by
[~sormu...@gmx.de]:
This table has module names and their artifact names extracted by a script from
Maven central:
https://github.com/sormuras/modules/blob/main/doc/Top1000-2020.txt.md (see also
the repo: https://github.com/sormuras/modules)
When looking at the Top 1000, you will se that all module names that can be
found on Maven Central use the package names / coordinate names. If you read
the JLS, they recommend for packages and modules only "simple names" for small
projects without large outreach.
Here is conclusion what he recommends:
https://sormuras.github.io/blog/2019-08-04-maven-coordinates-and-java-module-names.html
So I just repeat myself: Module names should really be unqiue. I don't care
about 9.0, because its not officially announced, but when we enable the module
system we should use unique names.
O should we rename also all packages in Lucene's sozurce code and strip off
org.apache?
> 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
