On Thu, 15 Apr 2010, Robert Muir wrote:
2010/4/15 Michael McCandless luc...@mikemccandless.com
I realize the migration tool has issues -- it fixes the hard
changes
but silently allows the soft changes to break (ie, your
analyzers my
not produce the same tokens,
On Apr 14, 2010, at 7:45, Yonik Seeley yo...@lucidimagination.com
wrote:
On Wed, Apr 14, 2010 at 10:39 AM, DM Smith dmsmith...@gmail.com
wrote:
Maybe have the index store the version(s) and use that when
constructing a
reader or writer?
That would cause a reindex to change behavior
On Thu, 15 Apr 2010, Earwin Burrfoot wrote:
Can't believe my eyes.
+1
Likewise. +1 !
Andi..
On Thu, Apr 15, 2010 at 01:22, Michael McCandless
luc...@mikemccandless.com wrote:
On Wed, Apr 14, 2010 at 12:06 AM, Marvin Humphrey
mar...@rectangular.com wrote:
Essentially, we're free to
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, 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
On Mar 16, 2010, at 11:47, Steven A Rowe sar...@syr.edu wrote:
On 03/16/2010 at 6:06 AM, Michael McCandless wrote:
Does anyone know how other projects fold in IRC...?
I gather from the deafening silence that we'll have to figure it out
as we go...
I think some (not all) of the
Issue Type: Bug
Components: Analysis
Affects Versions: 3.0
Reporter: Andi Vajda
In the vein of LUCENE-1126 and LUCENE-1390, StandardTokenizerImpl.jflex should
do a better job at understanding non-ASCII punctuation characters.
For example, its understanding
[
https://issues.apache.org/jira/browse/LUCENE-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-2244:
---
Attachment: StandardTokenizerImpl.jflex.diff
A patch expanding the understanding of the single
On Tue, 5 Jan 2010, Chris Hostetter wrote:
: https://issues.apache.org/jira/browse/LUCENENET-331). This begs the
: question, if Lucene.Net takes just this one patch, than Lucene.Net 2.9.1 is
: now 2.9.1.1 (which I personally don't like to see happening as I prefer to
: see a 1-to-1 release
Hi Uwe,
On Sun, 22 Nov 2009, Uwe Schindler wrote:
I have built the artifacts for the final release of Apache Lucene Java
3.0.0 a second time, because of a bug in the TokenStream API (found by Shai
Erera, who wanted to make bad things with addAttribute, breaking its
behaviour, LUCENE-2088)
of HEAD.
Andi..
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Andi Vajda [mailto:va...@osafoundation.org]
Sent: Tuesday, November 24, 2009 6:46 PM
To: java-dev@lucene.apache.org
Subject: Re: [VOTE
On Nov 8, 2009, at 5:10, Uwe Schindler u...@thetaphi.de wrote:
Juhu! Heavy commiting made it at least. I am back in Bremen now. It
was a pleasure to meet you all @ ApacheCon!
Likewise !
Andi..
Uwe
Mit einem Mobiltelefon von Sony Ericsson gesendet
Originalnachricht
Von:
On Tue, 13 Oct 2009, Mark Miller wrote:
For the record - I still don't see what we gain but confusion.
The major numbers don't have any significant meaning in terms of
features or advancements.
That's a perception we don't have control over.
A release incrementing the major release number
On Thu, 24 Sep 2009, Chris Hostetter wrote:
: - db/bdb fails to compile with 1.4 because of a ClassFormatError in one of
: the bundled libs, so this contrib is in reality 1.5 only.
there's not much we can do about that, no one can blame us if the
dependency requires 1.5
I don't think it
On Mon, 24 Aug 2009, Tim Smith wrote:
Here's my vote on the topic of 2.9 vs 3.0
Next release should be 2.9
This release provides TONs of new APIs for things like Hit Collection,
Scoring, Sorting, etc
If all the deprecated stuff were removed for the next release, this would
be impossible for
On Sun, 23 Aug 2009, Michael McCandless wrote:
Right, this (you can jump to 2.9, fix all deprecations, then easily
move to 3.0 and see no deprecations) is my understanding too, but I
don't see what's particularly useful about that. It does produce a
Lucene release that has zero deprecated
On Sun, 23 Aug 2009, Mark Miller wrote:
I'm still +1 on calling this 3.0 as I was before when you mentioned it.
Its a wakeup call that the upgrade is a bit major in certain areas.
In either case - 3.0 is more representative of what this release is IMO.
I also think we should allow new
On Sun, 23 Aug 2009, Michael McCandless wrote:
Looks like this build failed because downloads.osafoundation.org is
down (we download BDB JARs from there, for contrib/db).
This has happened a good number of times now... it'd be great to fix
the contrib/db/build.xml to just skip the tests when
On Jun 4, 2009, at 3:28, Michael McCandless
luc...@mikemccandless.com wrote:
Hmm -- problems downloading BDB's JARs from
downloadds.osafoundation.org again...
Yes, ISC, OSAF's ISP had a planned outage of 1.5 hr last night, CA
time, to replace their core router rack.
Andi..
Mike
On Wed, 20 May 2009, Michael McCandless wrote:
On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
On Wed, May 20, 2009 at 11:46 AM, Mark Miller markrmil...@gmail.com wrote:
Marvin Humphrey wrote:
Yeesh, that's evil. :(
It will be sweet, sweet justice if one
On Tue, 28 Apr 2009, Michael McCandless wrote:
Hmm -- this failed because the host downloads.osafoundation.org
fails to resolve. The contrib/db tests need to download the Berkeley
DB JARs from here.
Andi any idea what's up w/ that? Do we need to set a different
download location?
It
[
https://issues.apache.org/jira/browse/LUCENE-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda resolved LUCENE-1580.
Resolution: Duplicate
See https://issues.apache.org/jira/browse/LUCENE-1390
On Mar 18, 2009, at 13:01, Michael McCandless
luc...@mikemccandless.com wrote:
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler
On Feb 18, 2009, at 12:04, Michael McCandless
luc...@mikemccandless.com wrote:
I agree. Maybe also:
LUCENE-1465: NearSpansOrdered.getPayload does not return the
payload from the minimum match span
LUCENE-1453: Directory gets closed too early with IndexReader.reopen
LUCENE-1519:
On Wed, 11 Feb 2009, Michael McCandless wrote:
Hi Mike,
This looks like it could be LUCENE-1453 (fixed on trunk). Does this
exception happen on trunk Lucene?
I'm about to test this by applying this fix to 2.4.0 (if possible).
Are you opening the original reader w/ String or File path?
On Wed, 11 Feb 2009, Andi Vajda wrote:
Hi Mike,
This looks like it could be LUCENE-1453 (fixed on trunk). Does this
exception happen on trunk Lucene?
I'm about to test this by applying this fix to 2.4.0 (if possible).
Applying the patch attached to LUCENE-1453 to 2.4.0 seems to have
Isn't that depending on Java 1.5 ?
Andi..
On Feb 3, 2009, at 11:38, Michael McCandless
luc...@mikemccandless.com wrote:
I think that makes sense. I'll wait a day or so and then commit it
if there are no objections.
Mike
Jason Rutherglen wrote:
A simple way to make BitVector faster
On Tue, 3 Feb 2009, Michael McCandless wrote:
Do you mean the assert statement? That's available since 1.4.
Yeah, that's what I meant. 1.5 vs 1.4 is getting blurry :)
Andi..
Mike
Andi Vajda wrote:
Isn't that depending on Java 1.5 ?
Andi..
On Feb 3, 2009, at 11:38, Michael
On Fri, 30 Jan 2009, eks dev wrote:
I have used them for speeding up huge switch clauses in charset
normalization (eg lowercase and accent-plain form mapping). Big number of
accented characters (this causes big switch statement) that appear seldom
in corpus (big majority being not accented).
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654160#action_12654160
]
Andi Vajda commented on LUCENE-1390:
Thanks Mark !
add ISOLatinAccentFilter
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652875#action_12652875
]
Andi Vajda commented on LUCENE-1390:
Ah, I see now what you're asking for. Sorry
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652911#action_12652911
]
Andi Vajda commented on LUCENE-1390:
Great, I'll include Robert's change and try
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653045#action_12653045
]
Andi Vajda commented on LUCENE-1390:
This class includes all
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1390:
---
Attachment: ASCIIFoldingFilter.patch
This latest version supercedes the previous one and moves all
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653123#action_12653123
]
Andi Vajda commented on LUCENE-1390:
Mark, I attached a new version of the patch
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1390:
---
Attachment: (was: ISOLatinAccentFilter.java)
add ISOLatinAccentFilter and deprecate
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653139#action_12653139
]
Andi Vajda commented on LUCENE-1390:
Yep, I'm leaning that way too.
add
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652694#action_12652694
]
Andi Vajda commented on LUCENE-1390:
Could you please attach a patch for the change
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643152#action_12643152
]
Andi Vajda commented on LUCENE-1390:
Wow, Steve, I'm impressed. This is quite
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1390:
---
Attachment: ISOLatinAccentFilter.java
ISOLatinAccentFilter.java again, now with Unicode Latin
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632458#action_12632458
]
Andi Vajda commented on LUCENE-1390:
I think that would be a whole lot of typing
Components: Analysis
Environment: any
Reporter: Andi Vajda
The ISOLatin1AccentFilter is removing accents from accented characters in the
ISO Latin 1 character set.
It does what it does and there is no bug with it.
It would be nicer, though, if there was a more
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1390:
---
Attachment: ISOLatinAccentFilter.java
The new ISOLatinAccentFilter class, superceding
[
https://issues.apache.org/jira/browse/LUCENE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631946#action_12631946
]
Andi Vajda commented on LUCENE-1390:
Makes sense.
I did look at that block
I'm the one who originally lobbied for this patch to get the number of
patches required to compile Java Lucene (from .class files) with gcj down a
bit. I've since switched away from gcj, using jcc [1] instead which I wrote
for PyLucene originally.
That being said, if I were still using gcj
[
https://issues.apache.org/jira/browse/LUCENE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615001#action_12615001
]
Andi Vajda commented on LUCENE-1339:
That would work just as well !
Andi..
Add
On Fri, 18 Jul 2008, Yonik Seeley wrote:
Although I do wonder if incRef() and decRef() aren't more suitable
names. Just make those methods public, which the caveat that one
should not call them on a closed reader. They are expert level APIs
after all.
That would work just as well. The
Andi Vajda wrote:
I'd like to propose a patch for IndexReader but before I file a proper bug
and attach the (simple) patch, I want to check here if my approach is the
right one.
I have a server where a bunch of threads are handling search requests. I
have a another process that updates the index
- Java
Issue Type: New Feature
Reporter: Andi Vajda
Fix For: 2.3.2
From:
http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200807.mbox/[EMAIL
PROTECTED]
I have a server where a bunch of threads are handling search requests. I
have a another process
[
https://issues.apache.org/jira/browse/LUCENE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1339:
---
Attachment: lucene-1339.patch
Add IndexReader.acquire() and release() methods using IndexReader's
I'd like to propose a patch for IndexReader but before I file a proper bug
and attach the (simple) patch, I want to check here if my approach is the
right one.
I have a server where a bunch of threads are handling search requests. I
have a another process that updates the index used by the
Project: Lucene - Java
Issue Type: Bug
Components: Search
Affects Versions: 2.3.1
Reporter: Andi Vajda
Priority: Trivial
Currently, BoostingTermScorer, an inner class of BoostingTermQuery is not
accessible from outside the search.payloads
[
https://issues.apache.org/jira/browse/LUCENE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andi Vajda updated LUCENE-1234:
---
Attachment: patches-lucene-2.3.1
patch against lucene-2.3.1 sources
BoostingTermQuery's
[
https://issues.apache.org/jira/browse/LUCENE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578976#action_12578976
]
Andi Vajda commented on LUCENE-1234:
The inaccessible class is called
[
https://issues.apache.org/jira/browse/LUCENE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570903#action_12570903
]
Andi Vajda commented on LUCENE-1182:
Err, I meant to say the handy SimilarityDelegator
: Bug
Components: Search
Affects Versions: 2.3
Reporter: Andi Vajda
Priority: Minor
The handy SimilarityDelegator method is missing a scoreDelegator() delegating
method.
The fix is trivial, add the code below at the end of the class:
public float scorePayload
On Sat, 1 Dec 2007, Paul Elschot (JIRA) wrote:
Workaround in Searcher.java for gcj bug#15411 no longer needed
--
Key: LUCENE-1074
URL: https://issues.apache.org/jira/browse/LUCENE-1074
On Sat, 29 Sep 2007, Michael McCandless wrote:
The new PyLucene is built with a code generator and all public APIs and
classes are made available to Python. SerialMergeScheduler is available.
Wild! Does this mean PyLucene will track tightly to Lucene releases
going forward?
Yes, even more
On Sat, 29 Sep 2007, Andi Vajda wrote:
Ok, this could explain why the test is passing. In the test I only do one
batch of indexing, not several like here. I missed that difference. My
apologies. I'm going to change my test now and report back...
I finally isolated the bug into a simple Java
On Sat, 29 Sep 2007, Andi Vajda wrote:
I finally isolated the bug into a simple Java unit test. It indeed had to do
with doing multiple batches of document additions.
I forgot to say that I ran this with the most recent fixes for bug 1008.
To be precise, lucene svn rev 580605.
Andi
On Fri, 28 Sep 2007, Grant Ingersoll wrote:
I see 3 issues open against 2.3 still, plus 1 that are open against 2.2
I think the biggest issue before releasing is our confidence in the major
changes related to DocumentsWriter and the merge stuff, right?
Do we want to try to set a date for a
On Fri, 28 Sep 2007, Andi Vajda wrote:
I found a bug with indexing documents that contain fields with Term Vectors.
The indexing fails with 'reading past EOF' errors in what seems the index
optimizing phase during addIndexes(). (I index first into a RAMDirectory,
then addIndexes
On Fri, 28 Sep 2007, Michael McCandless wrote:
I tried all morning to isolate the problem but I seem to be unable
to reproduce it in a simple unit test. In my application, I've been
able to get errors by doing even less: just creating a FSDirectory
and adding documents with fields with term
On Tue, 24 Jul 2007, Grant Ingersoll wrote:
Well, it has been over a year since we have had the 1.5 debate (see
http://www.gossamer-threads.com/lists/lucene/java-dev/35972?search_string=Java%201.5;#35972)
and I think it is time we start accepting 1.5 code. Nutch, Solr, Hadoop all
use JDK 1.5
On Thu, 31 May 2007, Doug Cutting wrote:
Steven Parkes wrote:
Is there any particular reason that the version that takes a Directory[]
optimizes first?
There was, but unfortunately I can't recall it now. Index merging has
changed substantially since then, so, whatever it was, it may no
On Thu, 31 May 2007, Steven Parkes wrote:
Hmmm ... something's not meshing for me here.
If I understood what you've said, you have a DbD index to which you are
addIndexes'ing a memory index? I must have missed something, because
addIndexes pre- and post-optimizes the target (Dbd) index, not
On Tue, 29 May 2007, Chris Hostetter wrote:
: ...the issue of what to do about contrib/db/bdbd's native library
: dependencies should definitely be discussed.
:
: As the maintainer of the contrib/db tree, I should point out that indeed,
: the bdb part depends on a C release of Sleepycat's
On Fri, 18 May 2007, Chris Hostetter wrote:
Even if we get the neccessary native lib installed on the lucene zone for
nightly builds, that doesn't really help in the case of official releases
where a release manager builds locally -- assuming the tests are fine
because the nightly buidls are
On Fri, 18 May 2007, Andi Vajda wrote:
If the Runtime.loadLibrary() API can load the bdb native library, the tests
should be run, else they should be skipped with a warning. [1]
i suppose we could just define bdb test target to only run if some new
test.contrib.db.bdb property is set
On Sat, 19 May 2007, Sean Timm wrote:
Andi Vajda wrote on 5/18/2007, 9:50 PM:
As the maintainer of the contrib/db tree, I should point out that indeed,
the bdb part depends on a C release of Sleepycat's (now Oracle)
Berkeley DB.
Would it make sense to migrate to the BDB Java Edition
On Fri, 18 May 2007, Chris Hostetter wrote:
: +1 for renaming the 'test' target to 'test-core', and adding a 'test'
: target that depends on 'test-core' and 'test-contrib'. That's what
: other projects tend to do.
This proved a little tricker then i originally thought, but i've got it
On Tue, 27 Mar 2007, Matt Ericson wrote:
I am new to the group and was wondering why lucene is still on java 1.4 ?
Have you thought about moving to 1.5 ? What are the reasons for keeping it
1.4 ?
One of the reasons was that gcj [1][2] doesn't support Java 1.5. That's
changing with the
[
http://issues.apache.org/jira/browse/LUCENE-722?page=comments#action_12451809 ]
Andi Vajda commented on LUCENE-722:
---
Yes, you fixed it in one place but this file is actually duplicated in the
Lucene source tree.
The bug I filed was about
[ http://issues.apache.org/jira/browse/LUCENE-722?page=all ]
Andi Vajda reopened LUCENE-722:
---
contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThis.java is
still wrong.
DEFAULT spelled DEFALT in MoreLikeThis.java
Versions: 2.0.0
Environment: all
Reporter: Andi Vajda
Priority: Minor
DEFAULT is spelled DEFALT in
contrib/queries/src/java/org/apache/lucene/search/similar/MoreLikeThis.java
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly
[
http://issues.apache.org/jira/browse/LUCENE-722?page=comments#action_12451697 ]
Andi Vajda commented on LUCENE-722:
---
http://svn.osafoundation.org/pylucene/trunk/patches.lucene contains a patch
(among others) to fix this.
DEFAULT spelled
Hi all,
About ten days ago, I filed bug 676:
http://issues.apache.org/jira/browse/LUCENE-676
requesting that we promote Solr's PrefixFilter to the Java Lucene core.
Several people responded in favor:
[ http://issues.apache.org/jira/browse/LUCENE-676?page=all ]
Andi Vajda updated LUCENE-676:
--
Attachment: TestPrefixFilter.java
Here is another attachment by Yura providing the request unit test.
Promote solr's PrefixFilter into Java Lucene's core
[ http://issues.apache.org/jira/browse/LUCENE-676?page=all ]
Andi Vajda updated LUCENE-676:
--
Attachment: PrefixFilter.java
Attached is a version of PrefixFilter that could be added to the Lucene core as
submitted by Yura Smolsky, a PyLucene user
A PyLucene user just submitted a patch to PyLucene to integrate Solr's
PrefixFilter class. PyLucene is not PySolr but it looks like PrefixFilter has
nothing specific to Solr in it and PrefixFilter could be useful to regular
Lucene users as well.
Are there any objections to checking
On Tue, 11 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
I'd be interested in doing this but what is it that we're after in
'supporting gcj' actually ?
I think it would sufficient to:
1. Compile only .jar and .class with gcj (not .java).
2. Pass all unit tests on a single platform
On Tue, 11 Jul 2006, Doug Cutting wrote:
Probably this would get fixed more quickly if someone contributed a patch to
JavaCC. Even it were not committed, we could build our own version of
JavaCC. Any intrepid volunteers?
For patches that seem too kludgy to make it into Lucene's sources
On Tue, 11 Jul 2006, DM Smith wrote:
Eclipse has a built in compiler called ecj and it can compile Java 1.6 code
today. However, unless classes are provided at runtime for linking, one will
get build errors.
It looks like ecj is going to replace the gcj java front-end compiler thereby
On Tue, 11 Jul 2006, robert engels wrote:
It's been years and GCJ still doesn't have anywhere near full 1.4 classpath
libraries.
So now if we want to write code for Lucene we have to know what libraries are
available for GCJ?
GCJ is a joke.
It looks like classpath is quite close to 100%
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that we
will start accepting 1.5 features when a GCJ release supports those features.
Does that seem reasonable?
+1
Andi..
On Tue, 20 Jun 2006, DM Smith wrote:
We are planning to migrate from Swing to Eclipse's RCP/JFace/SWT and then we
can and would use GCJ. If Lucene goes to Java 5, we will need to re-examine
those plans.
If you are planning to compile Java Lucene with gcj you may want to take a
look at the
On Fri, 2 Jun 2006, jason rutherglen wrote:
It might be interesting to merge using BDB into Solr, as an option to
provide better realtime updates. Perhaps the replication could be used as
well in place of rsync? I don't have any experience with BDB replication,
anyone have thoughts on the
://www.sleepycat.com/docs/ref/lock/am_conv.html
Andi..
- Original Message
From: Andi Vajda [EMAIL PROTECTED]
To: java-dev@lucene.apache.org; jason rutherglen [EMAIL PROTECTED]
Sent: Friday, June 2, 2006 10:52:27 AM
Subject: Re: GData Server - Lucene storage
On Fri, 2 Jun 2006, jason
On Fri, 2 Jun 2006, Vic Bancroft wrote:
The following diff seemed to help build a nice native binary in my fedora.
The first modification makes using the new core archive file name and the
second avoids a problematic class . . .
You can actually compile all of Lucene + a bunch of contribs
On Sat, 27 May 2006, Yonik Seeley wrote:
On 5/27/06, Daniel Naber [EMAIL PROTECTED] wrote:
If someone wants to add 1.5-dependent modules to
the contrib area that would be okay for me though.
+1
As far as Java1.4 or Java1.5 for Lucene core, I agree that it would
almost be nicer for
On Sat, 27 May 2006, Chuck Williams wrote:
Andi Vajda wrote on 05/27/2006 12:01 PM:
On Sat, 27 May 2006, karl wettin wrote:
How about a binary 1.4-target distribution?
That's a great idea that might solve the problem as long as the
resulting bytecode is compatible with 1.4 and with gcj
On Mon, 2006-05-22 at 09:42 -0700, Doug Cutting wrote:
I propose to make Lucene release 2.0.0 this Friday, the 26th of May.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[
http://issues.apache.org/jira/browse/LUCENE-507?page=comments#action_12376874 ]
Andi Vajda commented on LUCENE-507:
---
My apologies, I didn't notice this until it was mentioned today.
The //required by gcj comment is not something I added or need
[
http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12376319 ]
Andi Vajda commented on LUCENE-555:
---
There is an implementation of the Lucene index store that is backed up by
Berkeley DB. Take a look at the 'db' contrib area:
http
[ http://issues.apache.org/jira/browse/LUCENE-536?page=all ]
Andi Vajda resolved LUCENE-536:
---
Resolution: Fixed
Your changes were integrated and committed (rev 394214).
Please, please, please, in the future when sending fixes in, send a proper
patch
The announcement about the Java Lucene 1.9 final release was made today but
common-build.xml stills lists 1.9-rc1-dev for the version property both on
the 1.9 branch and on the trunk. Is this an oversight ?
Andi..
-
To
On Tue, 28 Feb 2006, Doug Cutting wrote:
Andi Vajda wrote:
The announcement about the Java Lucene 1.9 final release was made today but
common-build.xml stills lists 1.9-rc1-dev for the version property both
on the 1.9 branch and on the trunk. Is this an oversight ?
I wouldn't read too
On Tue, 28 Feb 2006, Doug Cutting wrote:
Andi Vajda wrote:
Understood. What threw me off was the 'rc1-dev' part of the version on the
branch. I'd expect it to say 1.9 or 1.9-final since the .jar files produced
by a 1.9 branch checkout all say 1.9-rc1-dev even though the branch is past
[ http://issues.apache.org/jira/browse/LUCENE-482?page=all ]
Andi Vajda resolved LUCENE-482:
---
Fix Version: 1.9
Resolution: Fixed
Assign To: Andi Vajda
fixed in rev 366041, 'db' contrib area structure was rearranged to accomodate
multiple
On Thu, 5 Jan 2006, Aditya Liviandi wrote:
Is there anyone who could help me better understand the file structure
of the indexes though?
The Berkeley DB implementations in the 'db' contrib area write out blocks of
index data as fed by the Lucene Directory classes. It has no understanding of
1 - 100 of 106 matches
Mail list logo
