On Tue, Apr 26, 2011 at 11:34 PM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Tue, Apr 26, 2011 at 11:07 PM, Robert Muir <rcm...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
