Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <844979978.334241268888907233.JavaMail.jira@brutus.apache.org>
Date: Thu, 18 Mar 2010 05:08:27 +0000 (UTC)
From: "Shai Erera (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2323) reorganize contrib modules
In-Reply-To: <304767311.256581268590287174.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Shai Erera commented on LUCENE-2323:
------------------------------------

Robert - I think that's exactly what I was proposing. You indicated that there are some components under contrib that you cannot move around because their package names would change, and I said that I don't think their package names should change :). So you can move XMLQP under contrib/queryparsers and its package name will stay the same ...

I also think that at least for analyzers, having all of them under one contrib jar will allow us to improve the way our users interact w/ analyzers. Consider for example an AnalyzerFactory which when receiving a Locale returns a pre-configured Analyzer, the best one we can think of for that Locale. That's (to me) a great service to our users, and I don't see how we can do that if all analyzers are under different modules. Besides, analyzers are logically close to each other because they perform a very specific task. Refactoring the analysis API again would be easier of all of them were under the same root directory ... less chance of missing some.

Query parsers are different because I agree a user will likely pick one for his app and go with it. But I don't think we're talking about massive amount of code here right? So again it makes sense to bundle them up together. We can have a module-level documentation of the different query parsers, pros and cons for each, use cases etc., and then the user can pick. If jar size is important to someone, then I think that someone is already recompiling everything to include just what he needs, and so we're not hurting anyone here.

Therefore I see this reorg as a logical and important step towards modularization.

> reorganize contrib modules
> --------------------------
>
>                 Key: LUCENE-2323
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2323
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/*
>            Reporter: Robert Muir
>
> it would be nice to reorganize contrib modules, so that they are bundled together by functionality.
> For example:
> * the wikipedia contrib is a tokenizer, i think really belongs in contrib/analyzers
> * there are two highlighters, i think could be one highlighters package.
> * there are many queryparsers and queries in different places in contrib

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