[
https://issues.apache.org/jira/browse/LUCENE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-10348:
-----------------------------------
Description:
This is a followup after LUCENE-10335:
In LUCENE-10335 we fixed all Analyzers static constructors to not rely on the
analysis modules to export stopwords files. Nevertheless, it is currently
impossible to use CustomAnalyzer and refer to stopwords files in the analyzers
module, because those are hidden, [~rmuir] showed some examples of how this is
uesed. This would also make it impossible for Solr to reuse the resources files!
Basically we should make the stopwords files (and other resources) visible. We
have to options:
- open all packages with resources unconditionally
- open all packages with resources only to module "org.apache.lucene.core"
I prefer the second one. The problem with Java's module system is the
following: If you open a package, it is also open for (deep) reflection, which
we don't want. So my proposal is to only open those packages only to lucene
core, so the ModuleResourceLoader and ClasspathResourceLoader can see those
resources (and Solr would be able to delegate to these resource loaders if
needed).
I will adds a test in the distribution.tests package that verifies that
resources in all analysis packages are open.
was:
This is a followup after LUCENE-10335:
In LUCENE-10335 we fixed all Analyzers static constructors to not rely on the
analysis modules to export stopwords files. Nevertheless, it is currently
impossible to use CustomAnalyzer and refer to stopwords files in the analyzers
module, because those are hidden, [~rmuir] showed some examples of how this is
uesed. This would also make it impossible for Solr to reuse the resources files!
Basically we should make the stopwords files (and other resources) visible. We
have to options:
- open all packages with resources unconditionally
- open all packages with resources only to module "org.apache.lucene.core"
I prefer the second one. The problem with Java's module system is the
following: If you open a package, it is also open for (deep) reflection, which
we don't want. So my proposal is to only open those packages
I will adds a test in the distribution.tests package that verifies that
resources in all analysis packages are open.
> Make stopwords resources from analyzers modules visible to
> ClasspathResourceLoader and ModuleResourceLoader
> -----------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-10348
> URL: https://issues.apache.org/jira/browse/LUCENE-10348
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/other
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Priority: Major
>
> This is a followup after LUCENE-10335:
> In LUCENE-10335 we fixed all Analyzers static constructors to not rely on the
> analysis modules to export stopwords files. Nevertheless, it is currently
> impossible to use CustomAnalyzer and refer to stopwords files in the
> analyzers module, because those are hidden, [~rmuir] showed some examples of
> how this is uesed. This would also make it impossible for Solr to reuse the
> resources files!
> Basically we should make the stopwords files (and other resources) visible.
> We have to options:
> - open all packages with resources unconditionally
> - open all packages with resources only to module "org.apache.lucene.core"
> I prefer the second one. The problem with Java's module system is the
> following: If you open a package, it is also open for (deep) reflection,
> which we don't want. So my proposal is to only open those packages only to
> lucene core, so the ModuleResourceLoader and ClasspathResourceLoader can see
> those resources (and Solr would be able to delegate to these resource loaders
> if needed).
> I will adds a test in the distribution.tests package that verifies that
> resources in all analysis packages are open.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
