On 3/21/09 1:36 PM, Michael McCandless wrote:
And I don't think the sudden separation of "core" vs "contrib" should
be so prominent (or even visible); it's really a detail of how we
manage source control.
When looking at the website I'd like read that Lucene can do hit
highlighting, powerful que
[
https://issues.apache.org/jira/browse/LUCENE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688079#action_12688079
]
Grant Ingersoll commented on LUCENE-1550:
-
Hey Tom,
Few questions:
# Do you have
On Mar 21, 2009, at 7:23 AM, Grant Ingersoll wrote:
On Mar 21, 2009, at 11:26 AM, Michael McCandless wrote:
What if (maybe for 3.0, since we can mix in 1.5 sources at that
point?) we change how Lucene is bundled, such that core queries and
contrib/query/* are in one JAR (lucene-query-3.0.jar)
> Maybe he actually ends up buying LIA(2) :)
LIA/2 suffers the same false dichotomy, and it drives me crazy there
too: we put all "contrib" packages in a different chapter, even though
it'd make much more sense to cover all analyzers in one chapter, all
queries in one chapter, etc.
I find myself
On 3/21/09 11:26 AM, Michael McCandless wrote:
I think we are mixing up source code modularity with
bundling/packaging.
Honestly, I would not mind much where the source code lives in svn, so
long as a developer, upon downloading Lucene 2.9, can go to *one*
place (javadocs) for Lucene's "queries
On Mar 21, 2009, at 11:26 AM, Michael McCandless wrote:
What if (maybe for 3.0, since we can mix in 1.5 sources at that
point?) we change how Lucene is bundled, such that core queries and
contrib/query/* are in one JAR (lucene-query-3.0.jar)? And
lucene-analyzers-3.0.jar would include contrib/a
> Honestly, I would not mind much where the source code lives in svn, so
> long as a developer, upon downloading Lucene 2.9, can go to *one*
> place (javadocs) for Lucene's "queries & filters" and see
> {Int,Long}NumberRangeFilter in there.
>
> We are not there today: a developer must first reali
[
https://issues.apache.org/jira/browse/LUCENE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688012#action_12688012
]
Michael McCandless commented on LUCENE-652:
---
bq. Fine! In my opinion the little o
I think we are mixing up source code modularity with
bundling/packaging.
Honestly, I would not mind much where the source code lives in svn, so
long as a developer, upon downloading Lucene 2.9, can go to *one*
place (javadocs) for Lucene's "queries & filters" and see
{Int,Long}NumberRangeFilter i
I think I'd lean towards a third solution: tighten up
TopScoreDocCollector (make it final, remove ability to change its PQ,
make things private) and have it focus on high performance collection
by score. This is the default collector for Lucene searches so I think
keeping it high performance (no
On 3/21/09 12:27 AM, Michael Busch wrote:
+1. I'd love to see Lucene going into such a direction.
However, I'm a little worried about contrib's reputation. I think it
contains components with differing levels of activity, maturity and
support.
So maybe instead of moving things from core into c
11 matches
Mail list logo
