lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: modularization discussion
Date Thu, 05 May 2011 16:59:04 GMT
+1 to Mike's proposal here.  Each of these could easily be
patches/issues.  The top ones would probably be the basics, eg,
faceting and schemas.

As the easiest short term solution for allowing other systems to use
Solr or it's features, it would be great if a 'committer' responded to
SOLR-1431.  Eg, it's assigned to someone and they should respond.  The
issue should probably be unassigned or assigned to someone else.

Lucene is a great project that many people rely on.  Refactoring Solr
will help the project by allowing more people to do more things with
Lucene.  That's an overall 'good' thing for everyone.  Also have we
lost the ability to execute distributed queries in Lucene?

Taking a step back I'd ask some of the owners of the projects
mentioned why they do not simply submit patches directly to the Apache
Lucene project as opposed to starting their own external projects?

On Tue, May 3, 2011 at 9:49 AM, Michael McCandless
<> wrote:
> Isn't our end goal here a bunch of well factored search modules?  Ie,
> fast forward a year or two and I think we should have modules like
> these:
>  * Faceting
>  * Highlighting
>  * Suggest (good patch is on LUCENE-2995)
>  * Schema
>  * Query impls
>  * Query parsers
>  * Analyzers (good progress here already, thanks Robert!),
>    incl. factories/XML configuration (still need this)
>  * Database import (DIH)
>  * Web app
>  * Distribution/replication
>  * Doc set representations
>  * Collapse/grouping
>  * Caches
>  * Similarity/scoring impls (BM25, etc.)
>  * Codecs
>  * Joins
>  * Lucene core
> In this future, much of this code came from what is now Solr and
> Lucene, but we should freely and aggressively poach from other
> projects when appropriate (and license/provenance is OK).
> I keep seeing all these cool "compressed int set" projects popping
> up... surely these are useful for us.  Solr poached a doc set impl
> from Nutch; probably there's other stuff to poach from Nutch, Mahout,
> etc.
> Katta's doing something sweet with distribution/replication; let's
> poach & merge w/ Solr's approach.  There are various facet impls out
> there (Bobo browse/Zoie; Toke's; Elastic Search); let's poach & merge
> with Solr's.
> Elastic Search has lots of cool stuff, too, under ASL2.
> All these external open-source projects are fair game for poaching and
> refactoring into shared modules, along with what is now Solr and
> Lucene sources.
> In this ideal future, Solr becomes the bundling and default/example
> configuration of the Web App and other modules, much like how the
> various Linux distros bundle different stuff together around the Linux
> kernel.  And if you are an advanced app and don't need the webapp
> part, you can cherry pick the huper duper modules you do need and
> directly embedded into your app.
> Isn't this the future we are working towards?
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message