Lucene - Solr - Nutch
>
>
>
> - Original Message
> > From: Michael McCandless <[EMAIL PROTECTED]>
> > To: java-dev@lucene.apache.org
> > Sent: Friday, September 5, 2008 6:41:48 AM
> > Subject: Re: Moving SweetSpotSimilarity out of contrib
>
- Original Message
> From: Michael McCandless <[EMAIL PROTECTED]>
> To: java-dev@lucene.apache.org
> Sent: Friday, September 5, 2008 6:41:48 AM
> Subject: Re: Moving SweetSpotSimilarity out of contrib
>
>
> Chris Hostetter wrote:
>
> > : Another important driver
Chris Hostetter wrote:
The bottom line is that contribs are about modularization, and
compartmentilization of features. We want to be able to build small
compact jars with well defined dependencies so that if someone wants
basic
indexing plus highlighting they know exactly what jars they nee
Chris Hostetter wrote:
: Another important driver is the "out-of-the-box experience".
I honestly have no idea what an OOTB experience for Lucene-Java
means ...
For Solr i understand, For Nutch i understand ... for a java
library
Well... even though it's a "java library", Lucene still
: My thought was to move SSS to core as a step towards
: making it the default, if and when there is more evidence it is
: better than current default - it just felt right as a cautious
: step - I mean first move it to core so that it is more exposed
If people really want to make SSS the default
: Another important driver is the "out-of-the-box experience".
I honestly have no idea what an OOTB experience for Lucene-Java means ...
For Solr i understand, For Nutch i understand ... for a java library
The closest thing we can do to describing an OOTB experience is making a
good demo
: Contrib lacks many requirements of core code - it can be java 1.5, it doesn't
: have to be backward compatible, etc. Putting something in core ensures its
: treated as a Lucene first class citizen, stuff in contrib is not held to such
: strict standards.
"Contribs" as an idea lack those require
My thought was to move SSS to core as a step towards
making it the default, if and when there is more evidence it is
better than current default - it just felt right as a cautious
step - I mean first move it to core so that it is more exposed
and used, an only after a while, maybe, if there are mos
On Sep 3, 2008, at 3:00 PM, Michael McCandless wrote:
Obviously we can't default everything perfectly since at some point
there are hard tradeoffs to be made and every app is different, but if
SweetSpotSimilarity really gives better relevance for many/most apps,
and doesn't have any downsides (
On Wed, Sep 3, 2008 at 4:55 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote:
>> I suspect any attempts at "bundling" Lucene code may snowball until you've
>> rebuilt Solr.
>
> Yeah I guess it is... though Solr includes the whole webapp too, whereas I
> think there's a natural bundle that wouldn't
markharw00d wrote:
>>Another important driver is the "out-of-the-box experience".
>>we need a "standard distro" ...which would be the core plus cherry-
pick certain important contrib modules (highlighter,
>> SweetSpotSimilarity,snowball, spellchecker, etc.) and bundle them
together.
Is that
>>Another important driver is the "out-of-the-box experience".
>>we need a "standard distro" ...which would be the core plus
cherry-pick certain important contrib modules (highlighter,
>> SweetSpotSimilarity,snowball, spellchecker, etc.) and bundle them
together.
Is that not Solr, or at least
Another important driver is the "out-of-the-box experience".
It's crucial that Lucene has good starting defaults for everything
because many developers will stick with these defaults and won't
discover the wiki page that says you need to do X, Y and Z to get
better relevance, indexing speed, sear
On 09/03/2008 at 2:00 PM, Chris Hostetter wrote:
> On 09/03/2008 at 8:40 AM, Mark Miller wrote:
> > I havn't used it myself, so I won't guess (too much ), but the
> > question to me seems to be, is SweetSpot important enough to move to
> > core? Are there enough good reasons? And even if so, is it
I would agree with you if I was wrong about the contrib/core attention
thing, but I don't think I am. It seems as if you have been arguing that
contrib is really just an extension of core, on par with core, but just
in different libs, and to keep core lean and mean, anything not needed
in core
: saw, the distinction and rules are not quite clear. I would think though, if
: the new Similarity is really that much better than the old, it might actually
: benefit in core. There is no doubt core gets more attention on both the user
: and developer side, and important pieces with general usag
java-dev@lucene.apache.org
Sent: Wednesday, 3 September, 2008 13:21:34
Subject: Re: Moving SweetSpotSimilarity out of contrib
On Tue, Sep 02, 2008, Chris Hostetter wrote about "Re: Moving
SweetSpotSimilarity out of contrib":
>
> : >From a legal standpoint, whenever we need to
I think its a fair question that, regardless of the legal mumbo jumbo
provoking it, can be considered on the merits that it should be - is it
something important enough to bulk up the core with the trade off being
more people will find it helpful and can use it with slightly less hassle?
I hav
ussion has turned into a legal issue :-).
On Wed, Sep 3, 2008 at 3:21 PM, Nadav Har'El <[EMAIL PROTECTED]>wrote:
> On Tue, Sep 02, 2008, Chris Hostetter wrote about "Re: Moving
> SweetSpotSimilarity out of contrib":
> >
> > : >From a legal standpoint, whene
On Tue, Sep 02, 2008, Chris Hostetter wrote about "Re: Moving
SweetSpotSimilarity out of contrib":
>
> : >From a legal standpoint, whenever we need to use open-source code, somebody
> : has to inspect the code and 'approve' it. This inspection makes sure there
: >From a legal standpoint, whenever we need to use open-source code, somebody
: has to inspect the code and 'approve' it. This inspection makes sure there's
: no use of 3rd party libraries, to which we'd need to get open-source
: clearance as well.
:
: This process was done for Lucene core, but
>From a legal standpoint, whenever we need to use open-source code, somebody
has to inspect the code and 'approve' it. This inspection makes sure there's
no use of 3rd party libraries, to which we'd need to get open-source
clearance as well.
This process was done for Lucene core, but not for contr
On Sep 2, 2008, at 6:07 AM, Shai Erera wrote:
Hi,
Following Doron's quality work enhancements in TREC 2007 (http://wiki.apache.org/lucene-java/TREC_2007_Million_Queries_Track_-_IBM_Haifa_Team
), I was wondering if it's possible to move the SweetSpotSimilarity
to Lucene's main code stream (o
23 matches
Mail list logo
