[
https://issues.apache.org/jira/browse/LUCENE-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15206543#comment-15206543
]
Uwe Schindler commented on LUCENE-7129:
---------------------------------------
Nevertheless, the whole "filtering" javadocs approach is not useful to prevent
people from using the APIs. Nothing can forbid people or their stupid Eclipse
autocompleter to use the classes we marked as experimental.
The correct fix for this is coming with Java 9, but we can start implementing
it before:
- Move all internal APIs to a separate package (this is what Robert wants to do
anyways), e.g., {{org.apache.lucene.internal}}.
- Don't export this package in {{module-info.java}}, so it gets completely
invisible to anybody using the JAR file as a module ({{-modulepath}} instead of
{{-classpath}}). Only lucene's own modules are allowed to refer to those
modules.
- Javadoc would work automatically, because Java 9 Javadocs does not document
non-exported packages.
This approach should be done at some point anyways, but it needs some
refactoring of package names. Most is fine, but some JAR files share packages
with others. This is no longer possible with Java 9 modules! E.g., Misc modules
{{oal.index}} package would need to be renamed, because it conflicts with the
module exported by lucene-core.jar.
> Prevent @lucene.internal annotated classes from being in Javadocs
> -----------------------------------------------------------------
>
> Key: LUCENE-7129
> URL: https://issues.apache.org/jira/browse/LUCENE-7129
> Project: Lucene - Core
> Issue Type: Task
> Components: general/javadocs
> Reporter: David Smiley
> Priority: Minor
>
> It would be cool if we could prevent {{@lucene.internal}} classes from
> appearing in Javadocs we publish. This would further discourage use of
> internal Lucene/Solr classes that are public not for public consumption but
> only public so that the code can be accessed across Lucene/Solr's packages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]