Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
To: "general@lucene.apache.org" <general@lucene.apache.org>
Date: Tue, 9 Mar 2010 08:26:50 -0800
Subject: Re: [VOTE] merge lucene/solr development (take 3)
Thread-Topic: [VOTE] merge lucene/solr development (take 3)
Thread-Index: Acq/o1GDsN33HgpOT/apFXivvBCExAAAgCDu
Message-ID: <C7BBB6CA.DD81%Chris.A.Mattmann@jpl.nasa.gov>
In-Reply-To: <8f0ad1f31003090811y3549c7efm889d407027def5e2@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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, th=
e
>> time can come for integration. Parallel tracks allows projects to move
>> forward operationally, and enforces insulation, loose coupling and other
>> properties.
>=20
> Unfortunately, this experiment has already happened and has failed.
>=20
> 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? I=
f
so, what were the reasons?

>=20
> 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.

Cheers,
Chris=20

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++