On Wed, Apr 27, 2011 at 11:49 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > 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?
The benchmarking stuff definitely originated in lucene-land, there was much more lucene analysis than solr analysis in that module consolidation, and non-sandboxish stuff in lucene-contrib that may be refactored/moved to modules. > 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 my point was the namespace doesn't tell you what the dependencies of the modules are. "lucene" wouldn't mean that it depends on lucene-core only... (and depending what it is, may not depend on lucene-core at all) and "solr" wouldn't mean that it depends on solr-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. Of course! That's the whole point of refactoring a module out of some solr functionality. Actual dependencies (i.e. which modules depend on which modules) would be TBD of course. > Are there other (technical) objections to ongoing refactoring besides > this namespace problem? I don't think so in general - as I stated before, w.r.t. LUCENE-2883, later discussions led me to believe there was very little disagreement left (and I actually thought some of us had come to an agreement). -Yonik --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
