[
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421112#comment-13421112
]
Hoss Man commented on LUCENE-4044:
----------------------------------
bq. There is no magic. they have to put things in their classpath.
Just checking ... sometimes you and Uwe bust out stuff that is
indistinguishable from magic.
bq. But I think we should fix the examples and support (as the "new" syntax)
Hmmm... yeah i'm -0 on that part ... i mainly just worry that it would be
confusing for users if some places in the config (charfilter, tokneizer,
tokenfilter, analyzer) supported these short names, but other places
(fieldtype, requesthandler, serachcomponent, etc...) didn't and required a FQN
ClassName or solr.ClassName
---
FWIW: The other issue to consider here is how the packaging of these
"uber-module-jars" will work in Solr binary pacakges ... right now it's the
solr contribs that provide the factories that ensure the lucene modules they
depend on make it into the final tgx/zip files ... if lucene modules start
providing the factories themselves, we'll need some build.xml shenanigans to
copy those module jars into the solr package dirs.
> Add NamedSPILoader support to TokenizerFactory, TokenFilterFactory and
> CharFilterFactory
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-4044
> URL: https://issues.apache.org/jira/browse/LUCENE-4044
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/analysis
> Reporter: Chris Male
> Fix For: 4.0
>
> Attachments: LUCENE-4044.patch
>
>
> In LUCENE-2510 I want to move all the analysis factories out of Solr and into
> the directories with what they create. This is going to hamper Solr's
> existing strategy for supporting {{solr.*}} package names, where it replaces
> {{solr}} with various pre-defined package names. One way to tackle this is
> to use NamedSPILoader so we simply look up {{StandardTokenizerFactory}} for
> example, and find it wherever it is, as long as it is defined as a service.
> This is similar to how we support Codecs currently.
> As noted by Robert in LUCENE-2510, this would also have the benefit of
> meaning configurations could be less verbose, would aid in fully decoupling
> the analysis module from Solr, and make the analysis factories easier to
> interact with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
