I made a quick summary of the state of the module system support here. https://issues.apache.org/jira/browse/LUCENE-10328?focusedCommentId=17468676&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17468676
I plan to un-draft the PR and commit it back to main as it currently is. Dawid On Thu, Dec 16, 2021 at 6:32 PM Dawid Weiss <[email protected]> wrote: > Hello, > > So... I've been fiddling with the module system together with Uwe, > Tomoko and Chris. Here's a somewhat cleaned-up view of how the module > system can be added to Lucene. > > https://github.com/apache/lucene/pull/533 > > This is under LUCENE-10255. In short, some things do change: > > - note non-convention configurations in gradle (prefixed with > 'module') - these are there specifically to distinguish modular from > classpath dependencies. This helps enormously with setting up module > path for various tasks (ECJ, javac, runtime configurations for tests). > > - there is some intentional duplication between gradle dependencies > and module requirements, services in META-INF and inside the module > descriptor. Whether these can be or should be automatically generated > from one another is a larger question. The consistency of services and > exposed packages is currently verified by an automatic test. > Dependencies are not yet cross-checked (and it may be impossible to do > so, in general). > > - I tried to verify that Eclipse and IntelliJ work fine but there may be > quirks. > > - this patch does not try to change the API but, eventually, this will > have to follow. The modular linter already complains about, for > example, package-private classes being used as input/output types in > the public API (this check had to be disabled). > > If there are no objections I'd like to merge this patch in. Please do > review the diffs, experiment with your workflows and see if everything > works for you. > > Dawid >
