Segment size limit for compound files
-
Key: LUCENE-624
URL: http://issues.apache.org/jira/browse/LUCENE-624
Project: Lucene - Java
Type: Improvement
Components: Index
Reporter: Michael Busch
Priority: Minor
Hello ev
That did it. Thanks. Still struggeling to get the test to break in the right
spot. There does not seem a run-debug option.
Thanks again.
-Original Message-
From: robert engels <[EMAIL PROTECTED]>
Date: Tue, 11 Jul 2006 12:03:46
To:java-dev@lucene.apache.org
Subject: Re: Lucene/Ne
It is preinstalled, but you need to add it to your class path or run
configuration.
On Jul 11, 2006, at 11:54 AM, Peter Decrem wrote:
Thanks for the help. It seems to compile. Tests also ran. So
that's great. But when i go to src\test for example
TestAnalyzers.java to debug, I get err
Thanks for the help. It seems to compile. Tests also ran. So that's great.
But when i go to src\test for example TestAnalyzers.java to debug, I get
errors in the line import junit.framework.*.
I thought junit came preinstalled and why did the tests run?
But I definitely seem to be heading
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%
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.
On Jul 11, 2006, at 8:54 AM, Andi Vajda wrote:
On Tue, 11 Jul 2006, DM Smith wrote:
Ec
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
makin
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 (fo
On Jul 11, 2006, at 3:51 AM, 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 platfor
On Jul 11, 2006, at 12:17 AM, Daniel John Debrunner wrote:
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?
Seems potentially a little s
Andi Vajda wrote:
Just last week, a PyLucene user got it to work on Solaris. I have no
access to a Solaris machine to validate this. If I had my choice of
platform, I'd pick one of (in order of preference):
- Mac OS X (Intel or PPC)
- a recent Red Hat Linux since this is the one most gcj de
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.
Just
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.
This would provide an existence proof that Lucene
13 matches
Mail list logo
