[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomoko Uchida updated LUCENE-8566:
----------------------------------
Description:
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
- withTokenizer(Class<? extends TokenizerFactory> factory, Map<String,String>
params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory, String... params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory,
Map<String,String> params)
- addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
- addCharFilter(Class<? extends CharFilterFactory> factory, Map<String,String>
params)
Since the builder also has methods which take service names, it seems like that
above methods are unnecessary and a little bit misleading. Giving symbolic
names is preferable to implementation factory classes, but for now, users can
write code depending on implementation classes.
What do you think about deprecating those methods (adding {{@Deprecated}}
annotations) and deleting them in the future releases? Those are called by only
test cases so deleting them should have no impact on current lucene/solr
codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I
missed some point. I'll close it.)
was:
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
- withTokenizer(Class<? extends TokenizerFactory> factory, Map<String,String>
params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory, String... params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory,
Map<String,String> params)
- addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
- addCharFilter(Class<? extends CharFilterFactory> factory, Map<String,String>
params)
Since the builder also has methods which take service names, it seems like that
above methods are unnecessary and a little bit misleading. Giving symbolic
names is preferable to implementation factory classes, but for now, users can
write code that depending on implementation classes.
What do you think about deprecating those methods (adding {{@Deprecated}}
annotations) and deleting them in the future releases? Those are called by only
test cases so deleting them should have no impact on current lucene/solr
codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I
missed some point. I'll close it.)
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> ----------------------------------------------------------------------
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Reporter: Tomoko Uchida
> Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
> - withTokenizer(Class<? extends TokenizerFactory> factory,
> Map<String,String> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory, String...
> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory,
> Map<String,String> params)
> - addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
> - addCharFilter(Class<? extends CharFilterFactory> factory,
> Map<String,String> params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
