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

Michael McCandless commented on LUCENE-1151:
--------------------------------------------

Very good question ... I don't know.  It would be awesome (and, amazing) if 
JFlex enabled some kind of inheritance.

Since WikipediaTokenizer doesn't have the backwards compat requirement of 
StandardTokenizer, you can presumably just fix ACRONYM in WikipediaTokenizer to 
not match host names (ie hardwire to "true")?

> Fix StandardAnalyzer to not mis-identify HOST as ACRONYM by default
> -------------------------------------------------------------------
>
>                 Key: LUCENE-1151
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1151
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Analysis
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: LUCENE-1151.patch
>
>
> Coming out of the discussion around back compatibility, it seems best to 
> default StandardAnalyzer to properly fix LUCENE-1068, while preserving the 
> ability to get the back-compatible behavior in the rare event that it's 
> desired.
> This just means changing the replaceInvalidAcronym = false with = true, and, 
> adding a clear entry to CHANGES.txt that this very slight non back compatible 
> change took place.
> Spinoff from here:
>     http://www.gossamer-threads.com/lists/lucene/java-dev/57517#57517
> I'll commit that change in a day or two.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to