: Yep, those users probably already hate our backwards tests and the
: contrib tests too.
probably ... which is just another reason why it probably makes sense
sense to move "core" stuff from Lucene-Java into it's own "module" along
side solr, and other modules that get refactored out of Solr o
Hi Hoss,
> : > (i suspect a whole lot of people who only care about the core library are
> : > going to really adamantly not want to have to check out all of Solr just
> : > to work on the core)
> :
> : This wouldn't really be merged development now would it?
> : When I run 'ant test' I want the S
On Tue, Mar 16, 2010 at 12:39 AM, Chris Hostetter
wrote:
> And as a committer, you should be concerned about things like this ...
> that doesn't mean every user of Lucene-Java who wants to build from source
> or apply their own local patches is going to feel the same way.
>
Yep, those users prob
: > (i suspect a whole lot of people who only care about the core library are
: > going to really adamantly not want to have to check out all of Solr just
: > to work on the core)
:
: This wouldn't really be merged development now would it?
: When I run 'ant test' I want the Solr tests to run, to
On Tue, Mar 16, 2010 at 12:01 AM, Chris Hostetter
wrote:
> 4) should it be possible for people to check out Lucene-Java w/o
> checking out Solr?
>
> (i suspect a whole lot of people who only care about the core library are
> going to really adamantly not want to have to check out all of Solr just
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845697#action_12845697
]
Mark Miller commented on SOLR-1803:
---
bq. Actually the problem is that the effect of combin
: prime-time as the new solr trunk! Lucene and Solr need to move to a
: common trunk for a host of reasons, including single patches that can
: cover both, shared tags and branches, and shared test code w/o a test
: jar.
Without a clearer picture of how people envision development "overhead"
wor
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845691#action_12845691
]
Hoss Man commented on SOLR-1803:
Lance: i agree that the current semantics are either poorly
On Mon, Mar 15, 2010 at 11:43 PM, Mark Miller wrote:
>>
>> Solr moves to Lucene's trunk:
>> /java/trunk, /java/trunk/sol
>
> +1. With the goal of merged dev, merged tests, this looks the best to me.
> Simple to do patches that span both, simple to setup
> Solr to use Lucene trunk rather than jar
On 03/15/2010 11:28 PM, Yonik Seeley wrote:
So, we have a few options on where to put Solr's new trunk:
Solr moves to Lucene's trunk:
/java/trunk, /java/trunk/sol
+1. With the goal of merged dev, merged tests, this looks the best to
me. Simple to do patches that span both, simple to setup
Due to a tremendous amount of work by our newly merged committer
corps, the get-on-lucene-trunk branch (branches/solr) is ready for
prime-time as the new solr trunk! Lucene and Solr need to move to a
common trunk for a host of reasons, including single patches that can
cover both, shared tags and
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845656#action_12845656
]
Lance Norskog commented on SOLR-1803:
-
Actually the problem is that the effect of combin
On Mon, Mar 15, 2010 at 07:25:00PM -0400, Mark Miller wrote:
> We haven't meant to do anything official is why we havn't dropped onto
> the dev-list - we were just looking for a branch to hash out these
> patches.
Makes sense to me. This is the kind of thing you'd do on a local checkout
with g
On Mon, Mar 15, 2010 at 7:25 PM, Chris Hostetter
wrote:
> Hmmm... I'm not sure i understand how any declared CharFilter/TOkenizer
> combo will be able to deal with this any better, but i'll take your word
> for it.
you can see this behavior in SolrAnalyzer's reusableTokenStream
method, it re-use
Sorry - hit a bad keyboard short cut and sent this mid way through
writing it - please disregard and read the followup.
On 03/15/2010 07:21 PM, Mark Miller wrote:
On 03/15/2010 07:14 PM, Chris Hostetter wrote:
: Development on branches/solr to get on lucene trunk is progressing at
: a furious
: They would not be able to re-use if you did this, because when you
: call reset(Reader) on them, the Reader would not be wrapped.
Hmmm... I'm not sure i understand how any declared CharFilter/TOkenizer
combo will be able to deal with this any better, but i'll take your word
for it.
Kill it t
On 03/15/2010 07:14 PM, Chris Hostetter wrote:
: Development on branches/solr to get on lucene trunk is progressing at
: a furious (nay... ferocious) pace, pushed by the "not new, but new to
: solr" committers. Feels great to have everyone on the same team!
I feel like i must have missed out on
On Mon, Mar 15, 2010 at 7:18 PM, Chris Hostetter
wrote:
>
> In the case of these factories: can't we eliminate the Html*Tokenizers
> themselves, but make the *factories* return the neccessary *Tokenizer
> wrapped in an HtmlStripCharFilter ?
They would not be able to re-use if you did this, becaus
: Is there any concern with removing the deprecated HtmlStrip*Tokenizer
factories?
I'm not adverse to gutting *internal* deprecated classes on just about any
release (requiring plugin writers to deal with the deprecation) but if
it's possible to keep things working for users with no java knowl
: Development on branches/solr to get on lucene trunk is progressing at
: a furious (nay... ferocious) pace, pushed by the "not new, but new to
: solr" committers. Feels great to have everyone on the same team!
I feel like i must have missed out on some sort of discussion -- what was
the motiva
On Mon, Mar 15, 2010 at 5:30 PM, Shalin Shekhar Mangar
wrote:
> Is there a way we can fix LUCENE-2098 too?
>
I think this is good to fix, yet removing the deprecations is
unrelated to this slowdown.
The deprecated functionality (HtmlStrip*Tokenizer) is implemented in
terms of the slower CharFil
On Tue, Mar 16, 2010 at 2:09 AM, Robert Muir wrote:
> Hello,
>
> Is there any concern with removing the deprecated HtmlStrip*Tokenizer
> factories?
>
> These can be done with CharFilter instead and they have some problems
> with lucene's trunk.
>
> If no one objects, I'd like to remove these in t
On 03/15/2010 05:24 PM, Paul Borgermans wrote:
On Mon, Mar 15, 2010 at 9:39 PM, Robert Muir wrote:
Hello,
Is there any concern with removing the deprecated HtmlStrip*Tokenizer factories?
Maybe a communication issue, you need to read the source code or
javadocs to know it is depreca
On Mon, Mar 15, 2010 at 9:39 PM, Robert Muir wrote:
> Hello,
>
> Is there any concern with removing the deprecated HtmlStrip*Tokenizer
> factories?
>
Maybe a communication issue, you need to read the source code or
javadocs to know it is deprecated
> These can be done with CharFilter instead an
Hello,
Is there any concern with removing the deprecated HtmlStrip*Tokenizer factories?
These can be done with CharFilter instead and they have some problems
with lucene's trunk.
If no one objects, I'd like to remove these in the branch.
Otherwise, Uwe tells me there is some way to make them wor
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845474#action_12845474
]
Robert Muir commented on SOLR-1804:
---
Thanks for the confirmation the clusters are ok.
Wel
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845462#action_12845462
]
Stanislaw Osinski commented on SOLR-1804:
-
Yeah, the clusters look good. When you're
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845459#action_12845459
]
Stanislaw Osinski commented on SOLR-1804:
-
I was about to offer advice similar to Gr
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845455#action_12845455
]
Robert Muir commented on SOLR-1804:
---
Grant I am concerned about a possible BW break in Lu
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845453#action_12845453
]
Grant Ingersoll commented on SOLR-1804:
---
Robert, instead of tracking it down by brute
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845451#action_12845451
]
Robert Muir commented on SOLR-1804:
---
Hi Stanislaw:
Correct, I did not upgrade anything el
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845441#action_12845441
]
Stanislaw Osinski commented on SOLR-1804:
-
Hi Robert,
Lucene dependency is the only
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845419#action_12845419
]
Uwe Schindler commented on SOLR-1824:
-
It should be easy to fix. The init() method in th
Created SOLR-1823.
I attached a patch for this particular problem.
Any other places we missed this?
None, that I could spot,
there are so many warnings about unchecked castings rsp. not using Generics.
--
mit freundlichem Gruß,
Frank Wesemann
Fotofinder GmbH USt-IdNr. DE812854514
Sof
[
https://issues.apache.org/jira/browse/SOLR-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Wesemann updated SOLR-1823:
-
Attachment: SOLR-1823.patch
This patch uses String.valueOf( entry.getKey ) to write an entry's key
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845319#action_12845319
]
Yonik Seeley commented on SOLR-1824:
The partial field is created regardless of abortOnC
partial field types created on error
Key: SOLR-1824
URL: https://issues.apache.org/jira/browse/SOLR-1824
Project: Solr
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Yonik Seeley
XMLWriter throws ClassCastException on writing maps other than
-
Key: SOLR-1823
URL: https://issues.apache.org/jira/browse/SOLR-1823
Project: Solr
Issue Type: Improveme
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845301#action_12845301
]
Robert Muir commented on SOLR-1804:
---
I wonder if you guys have any insight why the results
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-1677:
Attachment: SOLR-1677-lucenetrunk-branch-3.patch
SOLR-1677-lucenetrunk-branch-2.patch
[
https://issues.apache.org/jira/browse/SOLR-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1814:
Fix Version/s: (was: 1.4)
> select count(distinct fieldname) in SOLR
> -
[
https://issues.apache.org/jira/browse/SOLR-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1814:
Affects Version/s: (was: 2.0)
(was: 1.6)
[
https://issues.apache.org/jira/browse/SOLR-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1799:
Fix Version/s: (was: 1.3)
1.5
> enable matching of "CamelCase
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845214#action_12845214
]
Uwe Schindler commented on SOLR-1677:
-
I also added support for instantiating Lucene Ana
44 matches
Mail list logo