[
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421114#comment-13421114
]
Robert Muir commented on LUCENE-4044:
-------------------------------------
{quote}
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
{quote}
Well solr can keep its verbose syntax then: I'll leave it alone. Ill just
support backwards (class=solr.xxx) via the SPI.
{quote}
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.
{quote}
Its not anything we arent dealing with already. We already have shenanigans
copying that stuff over. its just less jars.
> 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]
