lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 16:26:50 GMT
Hi Robert,

>> There might be, but as a first start, duplication is a quick way to get
>> going and experiment. As solutions that evolve over time are matured, the
>> time can come for integration. Parallel tracks allows projects to move
>> forward operationally, and enforces insulation, loose coupling and other
>> properties.
> Unfortunately, this experiment has already happened and has failed.
> Instead it just creates more work, especially when it comes time for
> code maintenance. This is one reason why Solr is still using
> deprecated analysis APIs and one reason why they cannot use Lucene
> trunk.

Can you provide more detail on how it's failed? Did it fail because Solr
wasn't able to upgrade to a newer Lucene that would fix the deprecations? If
so, what were the reasons?

> If there weren't so much duplication, then doing efforts such as this
> would be easier, instead of having to convert two SynonymFilters we
> would only have to convert one.

With which "hat" on? Where are you converting them? I'm guessing you mean
one for Solr and one for Lucene(-java), right?

I hear you on the duplication of patches/etc. Sadly, it's a trade in SE to
maintain good separation of concerns, which provides other benefits
(identification of load bearing walls; insulation of code changes so that
upstream or downstream providers aren't well affected, etc. etc.)

One potential solution to this was what was originally proposed by Mike: a
shared analyzers, that then Lucene(-java), Solr, and Nutch can choose to
depend on. That might help.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message