[ 
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421181#comment-13421181
 ] 

Robert Muir commented on LUCENE-4044:
-------------------------------------

{quote}
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?
{quote}

I can't make that contrib go away with this issue. It has a solr fieldtype as 
well for ICU.

Because of that, for this issue we can just keep the status quo and not remove 
any contribs.
Then there is nothing to deal with here :)

                
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to