[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845214#action_12845214
]
Uwe Schindler commented on SOLR-1677:
-
I also added support for instantiating Lucene
[
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-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-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-1677:
Attachment: SOLR-1677-lucenetrunk-branch-3.patch
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845301#action_12845301
]
Robert Muir commented on SOLR-1804:
---
I wonder if you guys have any insight why the results
XMLWriter throws ClassCastException on writing maps other than String,?
-
Key: SOLR-1823
URL: https://issues.apache.org/jira/browse/SOLR-1823
Project: Solr
Issue Type:
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
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845319#action_12845319
]
Yonik Seeley commented on SOLR-1824:
The partial field is created regardless of
[
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
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
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845419#action_12845419
]
Uwe Schindler commented on SOLR-1824:
-
It should be easy to fix. The init() method in
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845441#action_12845441
]
Stanislaw Osinski commented on SOLR-1804:
-
Hi Robert,
Lucene dependency is the only
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845451#action_12845451
]
Robert Muir commented on SOLR-1804:
---
Hi Stanislaw:
Correct, I did not upgrade anything
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=12845455#action_12845455
]
Robert Muir commented on SOLR-1804:
---
Grant I am concerned about a possible BW break in
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845459#action_12845459
]
Stanislaw Osinski commented on SOLR-1804:
-
I was about to offer advice similar to
[
https://issues.apache.org/jira/browse/SOLR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=12845474#action_12845474
]
Robert Muir commented on SOLR-1804:
---
Thanks for the confirmation the clusters are ok.
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
On Mon, Mar 15, 2010 at 9:39 PM, Robert Muir rcm...@gmail.com 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
On 03/15/2010 05:24 PM, Paul Borgermans wrote:
On Mon, Mar 15, 2010 at 9:39 PM, Robert Muirrcm...@gmail.com 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
On Tue, Mar 16, 2010 at 2:09 AM, Robert Muir rcm...@gmail.com 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
On Mon, Mar 15, 2010 at 5:30 PM, Shalin Shekhar Mangar
shalinman...@gmail.com 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
: 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
: 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
On Mon, Mar 15, 2010 at 7:18 PM, Chris Hostetter
hossman_luc...@fucit.org 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
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
: 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
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
On Mon, Mar 15, 2010 at 7:25 PM, Chris Hostetter
hossman_luc...@fucit.org 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
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
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845656#action_12845656
]
Lance Norskog commented on SOLR-1803:
-
Actually the problem is that the effect of
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
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
On Mon, Mar 15, 2010 at 11:43 PM, Mark Miller markrmil...@gmail.com 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
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845691#action_12845691
]
Hoss Man commented on SOLR-1803:
Lance: i agree that the current semantics are either poorly
: 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
[
https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845697#action_12845697
]
Mark Miller commented on SOLR-1803:
---
bq. Actually the problem is that the effect of
On Tue, Mar 16, 2010 at 12:01 AM, Chris Hostetter
hossman_luc...@fucit.org 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
: (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, too.
On Tue, Mar 16, 2010 at 12:39 AM, Chris Hostetter
hossman_luc...@fucit.org 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.
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 Solr
: 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 or
44 matches
Mail list logo
