On Wed, Apr 27, 2011 at 9:25 AM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Wed, Apr 27, 2011 at 6:28 AM, Michael McCandless > <luc...@mikemccandless.com> wrote: >> 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? > > And if it's a very core part of solr that we've tended to hang a lot of > new features on, etc, then the nature of that code should still > hopefully be "solrish".
I'm confused... aren't they all "solrish"? Like, of the refactorings on the table, which ones are not solrish? Is the real issue here that you want Solr's name to live on no matter how this code is refactored in the future? >> 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. > > That's because it was factored directly into Lucene-core, not into a module. OK. >> 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. > > But that won't be true... it's likely that many modules will depend on other > modules. Sure but that's fine? Each layer can depend on other stuff in its layer, or in stuff in the lower (more "core") layers. Solr depends on Solr stuff and modules and Lucene core. Modules depend on other modules an Lucene core. > But as I said... it seems only fair to meet half way and use the solr > namespace > for some modules and the lucene namespace for others. Actually I think a whole new namespace (Steven's suggestion) is a great idea? Would that work? (Else we'll be arguing on every module refactoring what namespace it should take...). Or, I would also be fine with naming all modules factored out of solr under the solr namespace, as long as we make it clear that you can use them w/o the rest of Solr. Are there other (technical) objections to ongoing refactoring besides this namespace problem? Mike http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
