lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Less drastic ways
Date Mon, 15 Mar 2010 10:51:08 GMT
On Sun, Mar 14, 2010 at 4:29 PM, Otis Gospodnetic
<otis_gospodnetic@yahoo.com> wrote:

> Even if we merge Lucene/Solr and we treat Solr as just another
> Lucene contrib/module, say, contributors who care only about Solr
> will still patch against Solr and Lucene developers or those people
> who have the itch for that functionality being in Lucene, too, will
> still have to poach/refactor and pull that functionality in Lucene
> later on.

Yes, people with their respective itches can still create Solr-only
and Lucene-only functions, after the merge.  We should not block any
feature from going in solely because it's not "factored" so that both
Lucene & Solr can use it.

But, no, poaching is no longer needed with merged dev -- we are free
to efficiently refactor at that point.  Merged, we don't need to have
full copies of the code in two projects, await releases to de-dup,
etc. -- code can just freely move back and forth within the project.
It's also more likely that someone wearing a Lucene hat will see the
Solr work going on and jump in and help to make it work in Lucene.

Merged dev makes refactoring much more efficient then poaching across
project lines.  Both achieve the same goals with time, it's just that
poaching is a much slower/more wasteful way to achieve it... (but of
course is the only option for disparate projects, eg, pulling stuff
from Nutch down into Lucene).

> Whether Solr is a separate project or a Lucene
> contrib/module that has its own user (and contributor) community
> that is not tightly integrated with Lucene's -dev community, the
> same thing will happen, no?

True, but much less efficiently (if we can only poach across project
lines).

> Maybe it will help if we made things visual for us visual peeps.  Is
> this, roughly, what the plan is:
>
> trunk/
>    lucene-core/
>    modules/
>        analysis/
>        wordnet/
>        spellchecker/
>        whatever/
>        ...
>        facets/
>        ...
>        functions/
>        solr/
>            dih/
>            ...

I honestly don't know what module structure we'll come up with!  It's
tbd'd....

But this looks like a good start :)

I think we'd also have a queryparser module (we have like 7 of them,
according to Robert ;), a queries module (I'd think functions lives
inside there).

Mike

Mime
View raw message