lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: Factor out a standalone, shared analysis package for Nutch/Solr/Lucene?
Date Fri, 26 Feb 2010 21:11:07 GMT
+1

On Fri, Feb 26, 2010 at 3:20 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> I think this is a good idea!  LuSolr ;)  (kidding)
>
> I agree with all of your points Yonik.
>
> What do other people think...?
>
> Mike
>
> On Wed, Feb 24, 2010 at 2:20 PM, Yonik Seeley <yonik@apache.org> wrote:
> > I've started to think that a merge of Solr and Lucene would be in the
> > best interest of both projects.
> >
> > Recently, Solr as pulled back from using Lucene trunk (or even the
> > latest version), as the increased amount of change between releases
> > (and in-between releases) made it impractical to deal with. This is a
> > pretty big negative for Lucene, since Solr is the biggest Lucene user
> > (where people are directly exposed to lucene for the express purpose
> > of developing search features).  I know Solr development has always
> > benefited hugely from users using trunk, and Lucene trunk has now lost
> > all the solr users.
> >
> > Some in Lucene development have expressed a desire to make Lucene more
> > of a complete solution, rather than just a core full-text search
> > library... things like a data schema, faceting, etc.  The Lucene
> > project already has an enterprise search platform with these
> > features... that's Solr.  Trying to pull popular pieces out of Solr
> > makes life harder for Solr developers, brings our projects into
> > conflict, and is often unsuccessful (witness the largely failed
> > migration of FunctionQueries from Solr to Lucene).  For Lucene to
> > achieve the ultimate in usability for users, it can't require Java
> > experience... it needs higher level abstractions provided by Solr.
> >
> > The other benefit to Lucene would be to bring features to developers
> > much sooner... Solr has had features years before they were developed
> > in Lucene, and currently has more developers working with it.  Esp
> > with Solr not using Lucene trunk, if a Solr developer wants a feature
> > quickly, they cannot add it to Lucene (even if it might make sense
> > there) since that introduces a big unpredictable lag - when that
> > version of Lucene make it's way into Solr.
> >
> > The current divide is a bit unnatural.  For maximum benefit of both
> > projects, it seems like Solr and Lucene should essentially merge.
> > Lucene core would essentially remain as it is, but:
> > 1) Solr would go back to using Lucene's trunk
> > 2) For new Solr features, there would be an effort to abstract it such
> > that non-Solr users could use the functionality (faceting, field
> > collapsing, etc)
> > 3) For new Lucene features, there would be an effort to integrate it into
> Solr.
> > 4) Releases would be synchronized... Lucene and Solr would release at
> > the same time.
> >
> > -Yonik
> >
>



-- 
Robert Muir
rcmuir@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message