lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: modularization discussion
Date Wed, 27 Apr 2011 10:28:15 GMT
On Tue, Apr 26, 2011 at 11:34 PM, Yonik Seeley
<yonik@lucidimagination.com> wrote:
> On Tue, Apr 26, 2011 at 11:07 PM, Robert Muir <rcmuir@gmail.com> wrote:
>> It appears there are some problems with modularization of the code,
>> especially between lucene and solr, so I would like for us to have a
>> discussion on this thread.
>
> The specifics of each case matter of course.

I agree.

> Some of the refactored
> code has been changed to use the lucene namespace, and it
> seems only fair that other code that has traditionally been the
> domain of Solr keep the solr namespace. This helps
> keep the proper mindset that code is not being moved "from
> solr to lucene" as too many people keep putting it, but it's being
> exposed to lucene users and is now shared.

Why impose namespace restrictions based on where code was originally
committed?  I think the namespace of refactored code should reflect
the nature of the code, not its original origins?

For example, when I refactored UnInvertedField, it split nicely into a
Solr piece and a core Lucene piece, and so I gave the core Lucene
piece then org.apache.lucene.index namespace.

I think leaving refactored code in the solr namespace sends the wrong
message (ie, that this module "depends" on Solr somehow).  The lucene
namespace makes it clear that it only depends on Lucene.

Eg, the patch on LUCENE-2995 (consolidating our various spell/suggest
impls) also consolidates everything under the lucene namespace, which
I think makes sense?

Mike

http://blog.mikemccandless.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message