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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
