[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856357#action_12856357
]
Michael McCandless commented on LUCENE-2386:
Patch looks good Shai!
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-1709.
-
Resolution: Fixed
I've propagated Shai's improvements to Solr.
Additionally, I added the ant
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-2386.
Resolution: Fixed
Committed revision 933613. (take #2)
IndexWriter commits unnecessarily on
Hi
I'd like to propose a relaxation on the Version API. Uwe, please read the
entire email before you reply :).
I was thinking, following a question on the user list, that the
Version-based API may not be very intuitive to users, especially those who
don't care about versioning, as well as very
I wholeheartedly support this anti-version riot :)
On Tue, Apr 13, 2010 at 19:27, Shai Erera ser...@gmail.com wrote:
Hi
I'd like to propose a relaxation on the Version API. Uwe, please read the
entire email before you reply :).
I was thinking, following a question on the user list, that the
On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera ser...@gmail.com wrote:
Hi
I'd like to propose a relaxation on the Version API. Uwe, please read the
entire email before you reply :).
I was thinking, following a question on the user list, that the
Version-based API may not be very intuitive to
[
https://issues.apache.org/jira/browse/LUCENE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2316:
---
Attachment: LUCENE-2316.patch
Patch clarifies the contract, fixes the directories to adhere to it
[
https://issues.apache.org/jira/browse/LUCENE-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-2111.
Resolution: Fixed
Wrapup flexible indexing
On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera ser...@gmail.com wrote:
I was thinking that we can add on Version a DEFAULT version, which the
caller can set. So Version.setDefault and Version.getDefault will be added,
as static members (more on the static-ness of it later). We then change the
[
https://issues.apache.org/jira/browse/LUCENE-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856479#action_12856479
]
Michael McCandless commented on LUCENE-2371:
Reminder to future self: make
Well the no-arg ctor will be using Version.getDefault() which will
throw an exception if not set, and delegate the call to the
Version-aware ctor.
On Tuesday, April 13, 2010, Robert Muir rcm...@gmail.com wrote:
On Tue, Apr 13, 2010 at 11:27 AM, Shai Erera ser...@gmail.com wrote:
I was
Hi Shai,
one of the problem I have is: That is a static default! We want to get rid of
them (and did it mostly, only some relicts remain), so there are no plans to
reimplement such a thing again. The badest one is BooleanQuery.maxClauseCount.
The same applies to all types of sysprops. As
[
https://issues.apache.org/jira/browse/LUCENE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856509#action_12856509
]
Earwin Burrfoot commented on LUCENE-2355:
-
- Norms do both backward and forward
Hello,
I am a PhD student working with the FindBugs project, at the University
of Maryland. FindBugs http://findbugs.sourceforge.net/ is a popular
open source static analysis tool that can analyze Java software and
identify bugs. We recently analyzed *Lucene*, and identified about 22
[
https://issues.apache.org/jira/browse/LUCENE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856520#action_12856520
]
Luke Forehand commented on LUCENE-2208:
---
I just opened a bug for what appears to be
That is a static default!
Yes Uwe ... I'm aware of that :)
But that's not a static default for Lucene ... only for the application, if
it chooses to use it ...
so there are no plans to reimplement such a thing again
Well ... that's not exactly what I'm proposing here. I'm not for
On Apr 13, 2010, at 11:09, Shai Erera ser...@gmail.com wrote:
That is a static default!
Yes Uwe ... I'm aware of that :)
But that's not a static default for Lucene ... only for the
application, if it chooses to use it ...
So you have two apps on the same vm and both choose to use this
On Tue, Apr 13, 2010 at 2:09 PM, Shai Erera ser...@gmail.com wrote:
Because the fact to the matter is - we invented Version to allow for
changes w/o breaking back-compat, while the backwards section in CHANGES
seems to grow from release to release (I know - I'm partly to blame for it
:)),
On Tue, Apr 13, 2010 at 11:17:56AM -0700, Andi Vajda wrote:
Using global statics is flawed.
+1.
I wonder if it's possible to solve this problem for Analyzers by decoupling
their distribution from the Lucene core and versioning them separately. I.e.
remove MatchVersion and increment individual
I like the concept of version, but I'm concerned about it too.
The current Version mechanism allows one to use more than one Version in
their code. Imagine that we are at 3.2 and one was unable to upgrade to
a most version for a particular feature. Let's also suppose that at 3.2
a new feature
On Tue, Apr 13, 2010 at 2:39 PM, Marvin Humphrey mar...@rectangular.comwrote:
I wonder if it's possible to solve this problem for Analyzers by decoupling
their distribution from the Lucene core and versioning them separately.
I.e.
remove MatchVersion and increment individual Analyzer
Dear Lucene Developers,
You are receiving this email because you have a login,
'java-dev@lucene.apache.org', on the Apache JIRA installation,
https://issues.apache.org/jira/
On April 6 the issues.apache.org server was hacked. The attackers were able to
install a trojan JIRA login screen and
Because the version mechanism is not a single value for the entire library
but rather feature by feature. I don't see how a global setter can help.
That's only true if we believe people use different Version values in
different places of their code ... and note that they will still be able to.
[
https://issues.apache.org/jira/browse/LUCENE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-2367:
---
Assignee: Grant Ingersoll
CartesianPolyFilterBuilder has problems around the poles
[
https://issues.apache.org/jira/browse/LUCENE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-2367.
-
Resolution: Fixed
Committed Nicolas' patch to trunk
CartesianPolyFilterBuilder has
[
https://issues.apache.org/jira/browse/LUCENE-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856565#action_12856565
]
Grant Ingersoll commented on LUCENE-2359:
-
Committed Nicolas' updates to trunk
[
https://issues.apache.org/jira/browse/LUCENE-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-2366.
-
Resolution: Fixed
Committed revision 933754.
LLRect.createBox returned box does not
On Apr 13, 2010, at 2:09 PM, Shai Erera wrote:
And I guess that what bothers me the most is that it feels to me like we're
trying to protect people from stuff we haven't yet received complaints on (at
least none that I'm aware of),
I think we have, they just aren't explicitly stated b/c
You (or someone else) has reset your password.
-
Your password has been changed to: MCwqNr
You can change your password here:
https://issues.apache.org/jira/secure/ViewProfile.jspa
Here are the details of your account:
I agree with Uwe. We shouldn't use non-final public statics.
Thinking out loud: Could IndexWriter/IndexReader propagate the Version
to the downstream classes (e.g. IndexWriter to Analyzers, IndexReader to
queries) if not previously explicitly set?
E.g. an IndexWriter calls setVersion on an
On Tue, Apr 13, 2010 at 12:41 PM, Uwe Schindler u...@thetaphi.de wrote:
Hi Shai,
one of the problem I have is: That is a static default! We want to get rid
of them (and did it mostly, only some relicts remain), so there are no plans
to reimplement such a thing again. The badest one is
Priceless
On Wed, Apr 14, 2010 at 00:53, j...@apache.org wrote:
You (or someone else) has reset your password.
-
Your password has been changed to: MCwqNr
You can change your password here:
LOL!
This user is assigned to very old bugzilla issues :-)
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: j...@apache.org [mailto:j...@apache.org]
Sent: Tuesday, April 13, 2010 10:54 PM
To:
I changed the password, so its no longer public.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Uwe Schindler [mailto:u...@thetaphi.de]
Sent: Tuesday, April 13, 2010 11:59 PM
To:
A, good. That means the very long e-mail that came to my regular account
about someone hacking the JIRA server is bogus too I assume..
Erick
On Tue, Apr 13, 2010 at 5:58 PM, Uwe Schindler u...@thetaphi.de wrote:
LOL!
This user is assigned to very old bugzilla issues :-)
-
Uwe
It wasn't
On Wed, Apr 14, 2010 at 02:06, Erick Erickson erickerick...@gmail.com wrote:
A, good. That means the very long e-mail that came to my regular account
about someone hacking the JIRA server is bogus too I assume..
Erick
On Tue, Apr 13, 2010 at 5:58 PM, Uwe Schindler
On Tue, Apr 13, 2010 at 6:06 PM, Erick Erickson erickerick...@gmail.com wrote:
A, good. That means the very long e-mail that came to my regular account
about someone hacking the JIRA server is bogus too I assume..
Erick
Not sure about the mail, but that part is true...
On Tue, 13 Apr 2010, Erick Erickson wrote:
A, good. That means the very long e-mail that came to my regular account
about someone hacking the JIRA server is bogus too I assume..
Err, no, it's real. You should change your password.
Andi..
Erick
On Tue, Apr 13, 2010 at 5:58 PM, Uwe
Oops, that'll teach me to just skim things, won't it?
Erick
On Tue, Apr 13, 2010 at 6:14 PM, Andi Vajda va...@osafoundation.org wrote:
On Tue, 13 Apr 2010, Erick Erickson wrote:
A, good. That means the very long e-mail that came to my regular
account
about someone hacking the JIRA
[
https://issues.apache.org/jira/browse/LUCENE-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12856670#action_12856670
]
Luke Forehand commented on LUCENE-2208:
---
Sorry for what seems like cross posting,
FYI, this is for real. Some have asked me if it is made up. I don't know who
owns that user, so we should ask on infra, I suspect. Also, this applies to
all user accounts too on JIRA.
On Apr 13, 2010, at 12:25 PM, r...@apache.org wrote:
Dear Lucene Developers,
You are receiving this
Hi Grant,
It is that user, who is assigned to the very early JIRA issues, e.g.:
https://issues.apache.org/jira/browse/LUCENE-1
I changed the password of this user in response to that email (for security),
but I think we should simply let infra remove it. The problem is, almost
anybody can
Hi Nat:
Great analysis!
Some of them DO seem to be bugs! Maybe findbugs can be enabled as part
of the build?
-John
On Tue, Apr 13, 2010 at 11:01 AM, Nat Ayewah aye...@cs.umd.edu wrote:
Hello,
I am a PhD student working with the FindBugs project, at the University of
Maryland.
I wonder if that user was setup a while ago as a way of getting update messages
to the mailing list (maybe in the very early days of JIRA before notification
schemes). I'd suggest we disable the account.
-Grant
On Apr 13, 2010, at 8:08 PM, sebb wrote:
On 14/04/2010, Uwe Schindler
On Wed, Apr 14, 2010 at 01:08:41AM +0100, sebb wrote:
On 14/04/2010, Uwe Schindler u...@thetaphi.de wrote:
Hi Grant,
It is that user, who is assigned to the very early JIRA issues, e.g.:
https://issues.apache.org/jira/browse/LUCENE-1
I changed the password of this user in response
On Tue, Apr 13, 2010 at 02:46:56PM -0400, Robert Muir wrote:
Unlike other components in Lucene, Analyzers get hit the worst because any
change is basically a break, and there's really not any other option besides
Version to implement any backwards compatibility for them.
New class names would
On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey mar...@rectangular.comwrote:
New class names would work, too.
I only mention that for the sake of completeness, though -- it's not a
suggestion.
Right, to me this is just as bad.
In my eyes, the Version thing really shows the problem with
47 matches
Mail list logo
