lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <yo...@lucidimagination.com>
Subject Re: modularization discussion
Date Thu, 28 Apr 2011 01:23:23 GMT
On Wed, Apr 27, 2011 at 11:49 AM, Michael McCandless
<lucene@mikemccandless.com> wrote:
> On Wed, Apr 27, 2011 at 9:25 AM, Yonik Seeley
> <yonik@lucidimagination.com> wrote:
>> On Wed, Apr 27, 2011 at 6:28 AM, Michael McCandless
>> <lucene@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message