On 2010-03-09 05:24, Grant Ingersoll wrote:

> In the end, for me anyway, the current separation hurts Lucene a good
> deal as much as it hurts Solr, if not more.  Likewise, I wish some of
> the Nutch committers would speak up, as I'm sure there are some
> pieces of Nutch that are "core" too, but for a lack of visibility
> down lower in Lucene committer wise, especially as Nutch as looking
> to refactor into more components.  Obviously not the crawling stuff,
> but perhaps some of Nutch's analyzer and low level Lucene stuff would
> make sense to be pushed lower in the stack.

With my Nutch hat on, I'm -0 to this current vote.

If the primary devs really insist on going this way, so be it, but I 
think that long-term it brings more challenges than it solves, among 
them the danger that Lucene ceases to be a general purpose Java search 
library (where being Java-centric is nothing wrong) and caters too much 
to Solr's needs at the expense of other projects.

Re: Nutch components - those that are reusable in Lucene or Solr 
contexts eventually find their way to respective projects, witness e.g. 
CommonGrams. Other stuff makes sense only in Nutch and it would be a 
mistake to push it by force to become e.g. a contrib module in Lucene if 
it's not applicable to a majority of Lucene community. Refactoring to 
increase reuse doesn't mean we have to merge Nutch with Lucene, it's 
just a cleaner separation of concerns. Anyway, that's not the topic of 
the current vote.

-- 
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com