[
https://issues.apache.org/jira/browse/LUCENE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313763#comment-17313763
]
Tomoko Uchida commented on LUCENE-9623:
---------------------------------------
bq. What packages are exported and what are kept private - and how do we make
the decision or get consensus about it (upon such a large codebase)?
Still I haven't come up with good idea for that, but - we might be able to get
some statistics/numbers by searching OSS repositories that uses Lucene public
APIs. For example, GitHub provides APIs to allow programmatically search
repositories that are hosted on it. Of course OSS code may be only a small
fraction of the whole though, concrete real world use cases could give us some
clues to decide what classes/packages should be kept public? Just a random
thought.
> 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: main (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
