[
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421178#comment-13421178
]
Hoss Man commented on LUCENE-4044:
----------------------------------
{quote}
bq. I think so too, but since some of this is contentious, lets just leave it
for a future issue.
Yeah fair enough.
{quote}
I wasn't objecting to supporting the shortenend syntax, i'm just worried that
using it in the examples might confuse people when the same shortened syntax
doesn't work in other places.
bq. Its not anything we arent dealing with already. We already have shenanigans
copying that stuff over. its just less jars.
it's something we're dealing with already, but the way we are dealing with it
will probably need to change in some cases...
right now (some) lucene-module jars get copied over into solr binary artifacts
is because there are solr contribs that provide the factories and have
build.xml files that copy the jars - if (some) solr contribs go away because
the factories are included directly lucene module, then the solr contrib
build.xml files will go away, and then we need new/differnet ways to ensure
those lucene module jars get copied into solr binary packages ... correct?
> 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]
