[
https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240206#comment-17240206
]
Dawid Weiss commented on LUCENE-9623:
-------------------------------------
Hi Tomoko. I think you could use gradle itself to generate that module-info
(even if it's temporary) - it'd be easier to collect dependencies, etc?
If you ask me, I'd generate explicit exports (not open modules). This way
encapsulation is enforced from the start and there is no need to backtrack
later. Other than that I really have no idea how to work with the module system
at the build level - this is uncharted territory. Makes me think if we
shouldn't wait until the build is split into Solr and Lucene - Lucene treated
independently seems to be easier than combined with Solr's dependencies.
> Add module descriptor (module-info.java) to lucene jars
> -------------------------------------------------------
>
> Key: LUCENE-9623
> URL: https://issues.apache.org/jira/browse/LUCENE-9623
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
> Affects Versions: master (9.0)
> Reporter: Tomoko Uchida
> Priority: Major
> Attachments: generate-all-module-info.sh
>
>
> For a starter, module descriptors can be automatically generated by jdeps
> utility.
> There are two choices.
> 1. generate "open" modules which allows reflective accesses with
> --generate-open-module option
> 2. generate non-open modules with --generate-module-info option
> Which is the better - not fully sure, but maybe 2 (non-open modules)?
> Also, we need to choose proper module names - just using gradle project path
> for it is OK?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
