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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org