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
