lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <>
Subject [jira] Commented: (LUCENE-1728) Move SmartChineseAnalyzer & resources to own contrib project
Date Tue, 21 Jul 2009 09:36:14 GMT


Simon Willnauer commented on LUCENE-1728:

bq. I don't want to sound like a complainer since I don't have a patch to fix these things,
but I want to list some things that I would like to fix/refactor also.

 :) pushing things forward is not complaining to me. I agree with you points I did not look
closely into implementation details but rather on structural things. Apparently we both agree
that we have work to do on this and I guess we can work out good solutions in the future together.
Let's just move the classes into it's own subdir as you already did and keep the structure
as it is (with the smallest changes - some classes have to be moved). If you could provide
a patch I will commit the refactoring and we open a new issue for 3.*. 
This solution seems to be ideal as 2.9 release is quite close...


> Move SmartChineseAnalyzer & resources to own contrib project
> ------------------------------------------------------------
>                 Key: LUCENE-1728
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/analyzers
>            Reporter: Simon Willnauer
>            Assignee: Simon Willnauer
>            Priority: Minor
>             Fix For: 2.9
>         Attachments: LUCENE-1728.txt, LUCENE-1728.txt, LUCENE-1728.txt
> SmartChineseAnalyzer depends on  a large dictionary that causes the analyzer jar to grow
up to 3MB. The dictionary is quite big compared to all the other resouces / class files contained
in that jar. 
> Having a separate analyzer-cn contrib project enables footprint-sensitive users (e.g.
using lucene on a mobile phone) to include analyzer.jar without getting into trouble with
disk space.
> Moving SmartChineseAnalyzer to a separate project could also include a small refactoring
as Robert mentioned in [LUCENE-1722|] several
classes should be package protected, members and classes could be final, commented syserr
and logging code should be removed etc.
> I set this issue target to 2.9 - if we can not make it until then feel free to move it
to 3.0

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:
For additional commands, e-mail:

View raw message