Make all classes that have a close() methods instanceof Closeable (Java 1.5)
Key: LUCENE-1945
URL: https://issues.apache.org/jira/browse/LUCENE-1945
Project: Lucene - Java
Remove deprecated TokenStream API
-
Key: LUCENE-1946
URL: https://issues.apache.org/jira/browse/LUCENE-1946
Project: Lucene - Java
Issue Type: Task
Components: Analysis, contrib/analyzers
[
https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762000#action_12762000
]
Uwe Schindler commented on LUCENE-1558:
---
We have deprecated all these methods and I
[
https://issues.apache.org/jira/browse/LUCENE-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1946:
--
Attachment: LUCENE-1946.patch
Short and simple patch for Lucene core. The tests were modified
On 10/4/09 3:31 AM, Mark Miller wrote:
Ted Dunning wrote:
The builder pattern and the config argument to a factory both have the
advantage that you can limit changes after creating an object. Some
things are just bad to change in mid-stream. The config argument is
nice in that you can pass
> >> The builder pattern and the config argument to a factory both have the
> >> advantage that you can limit changes after creating an object. Some
> >> things are just bad to change in mid-stream. The config argument is
> >> nice in that you can pass it around to different stake holders, but
>
[
https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762009#action_12762009
]
Michael McCandless commented on LUCENE-1558:
bq. Do you want to put them back
[
https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762012#action_12762012
]
Paul Elschot commented on LUCENE-1257:
--
Uwe, thanks for adding the changes.txt entry
[
https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762011#action_12762011
]
Uwe Schindler commented on LUCENE-1558:
---
Kr, I rewrote all tests to add this par
I don't think we should do both. Suddenly, all code snippets (in
javadocs, tutorials, email we all send, etc.) can be one pattern or
the other, with each of us choosing based on our preference. Or,
mixed.
I think this just causes confusion. It'd suddenly become alot like
differences of opinion
[
https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762014#action_12762014
]
Michael McCandless commented on LUCENE-1558:
But, the tests can keep that chan
[
https://issues.apache.org/jira/browse/LUCENE-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-1946:
--
Attachment: LUCENE-1946.patch
Some more changes and additional tests (removed by the backwards
On Sun, Oct 4, 2009 at 5:53 AM, Michael McCandless
wrote:
> 1 Do we prevent config settings from changing after creating an
> IW/IR?
>
> 2 Do we use factory or ctor to create IW/IR?
>
> On #1, we are technically taking something away. Are we sure no users
> find the freedom to change IW sett
[
https://issues.apache.org/jira/browse/LUCENE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761997#action_12761997
]
Thomas D'Silva edited comment on LUCENE-1910 at 10/4/09 10:21 AM:
--
[
https://issues.apache.org/jira/browse/LUCENE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated LUCENE-1910:
---
Attachment: (was: LUCENE-1910.patch)
> Extension to MoreLikeThis to use tag information
[
https://issues.apache.org/jira/browse/LUCENE-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1929:
Attachment: LUCENE-1929.patch
The 2.9.1 fix
> Highlighter doesn't support NumericRangeQuery or de
As I stated in my last email, there's zero difference between
settings+static factory and builder except for syntax. Cannot
understand what Mark, Mike are arguing about.
Right now I offer to do two things, in any possible way - eradicate as
much broken/spahetti-like runtime state change from IW and
Earwin Burrfoot wrote:
> As I stated in my last email, there's zero difference between
> settings+static factory and builder except for syntax. Cannot
> understand what Mark, Mike are arguing about.
>
Sounds like we are arguing that we don't like the syntax then...
> kill setting methods that de
On Sun, Oct 04, 2009 at 03:04:13PM -0400, Mark Miller wrote:
> Earwin Burrfoot wrote:
> > As I stated in my last email, there's zero difference between
> > settings+static factory and builder except for syntax. Cannot
> > understand what Mark, Mike are arguing about.
> >
> Sounds like we are arg
On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote:
> 1 Do we prevent config settings from changing after creating an
> IW/IR?
Any settings conveyed via a settings object ought to be final if you want
pluggable index components. Otherwise, you need some nightmarish notifica
> On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote:
>
> > 1 Do we prevent config settings from changing after creating an
> > IW/IR?
>
> Any settings conveyed via a settings object ought to be final if you want
> pluggable index components. Otherwise, you need some nightm
21 matches
Mail list logo