Yes I figured it has to do with the runner. Good though that I can control
it with a -Dtests.timeout property.
I guess that I need to specify that as sysproperty in my build.xml?
Shai
On Wed, May 2, 2012 at 1:39 PM, Dawid Weiss wrote:
> > Can I use the randomized.jar with Lucene 3.6 test-framew
Hi
Someone asked why the following tiny test does not work:
String text = "Hello world1. Hello world2";
Tokenizer tokenizer = WhitespaceTokenizer(Version.LUCENE_36, new
StringReader(text));
int count = 0;
while (tokenizer.incrementToken()) {
count++;
}
assertEquals(4,count);
//
t needs to
be fixed) can happen under that issue.
Shai
On Sun, May 13, 2012 at 11:32 AM, Shai Erera wrote:
> Hi
>
> Someone asked why the following tiny test does not work:
>
> String text = "Hello world1. Hello world2";
> Tokenizer tokenizer = WhitespaceTokenizer
Hi
I tried to run a test with -Dtests.iters=100 and it doesn't work:
-- from eclipse, nothing ran, not even once
-- from cmd-line, the test was run once
I did "svn up", then "ant clean clean-jars resolve eclipse" and tried
again, same results
Does it work for anyone?
Shai
Thanks for the explanation.
The cmd-line I used is:
ant test -Dtestcase=TestDirectoryTaxonomyWriter
-Dtestmethod=testConcurrency -Dtests.iters=100
I see in your example that you use -Dtests.method, and I tried that in
eclipse and it worked with -Dtests.iters. I wonder why it didn't work from
cmd
Found the bug -- it's a concurrency issue in DirTaxoWriter -- it now
supports addCategory being called concurrently, however not all code paths
support it well. I'll reopen LUCENE-4061 where these changes were made. The
solution shouldn't be too complicated.
Sorry for noise
Shai
On Sat, Jun 9, 2
Thanks Dawid,
I guess if it just spelled IGNORED/A, I wouldn't think it's a typo. If it's
possible, can we have it spelled correctly? It's not critical if it's too
much work.
Shai
On Tue, Jun 12, 2012 at 9:20 PM, Dawid Weiss
wrote:
> Hi Shai.
>
> I think this question may be of relevance to oth
Welcome Greg !
Shai
On Thu, Jun 21, 2012 at 1:56 PM, Erick Erickson wrote:
> I'm pleased to announce that Greg Bowyer has been added as a
> Lucene/Solr committer.
>
> Greg:
> It's a tradition that you reply with a brief bio.
>
> Your SVN access should be set up and ready to go.
>
> Congratulatio
Hi
I ran SOLR tests today and I've noticed this print appearing several times:
[junit]
[junit] - Standard Error -
[junit] 14.okt.2010 12:14:28
org.apache.solr.common.util.ConcurrentLRUCache finalize
[junit] SEVERE: ConcurrentLRUCache was not destroyed p
Thanks for the explanation Robert !
Shai
On Thu, Oct 14, 2010 at 11:25 AM, Robert Muir wrote:
> On Thu, Oct 14, 2010 at 5:18 AM, Shai Erera wrote:
> > Hi
> >
> > I ran SOLR tests today and I've noticed this print appearing several
> times:
>
What we use to do is run 'ant test' with a redirection of standard output to
a file. That way, the errors stand out - they appear in the console, and the
rest of the test output goes to the file.
Don't know if that's what you want, but it sure makes it much easier to spot
the failing tests.
Shai
Hi
I understand the assertions in Analyzer to enforce 'final' on those methods,
but I wanted to ask why do we care if a user's code does not declare them
final? Why fail the tests on it? Can we change the assertion to fail if the
code from o.a.l?
The thing is, we run tests w/ -ea to catch all sor
I still don't understand how not declaring my tokenStream and
reusableTokenStream final can break anything. The methods are there (in my
analyzers), and if I risk overriding them somewhere else it's my problem.
What am I missing?
To add to your email - I too didn't encounter an analyzer that cann
led analyzers for conformance. If
> you don’t like that, you can simply disable assertions for the
> org.apache.lucene package.
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
e code, and we document the risks of not overriding
reusableTokenStream.
Can't we change the assertion to not fail if the class declares
reusableTokenStream, yet nothing is final? Wouldn't that avoid the issues
you've mentioned?
Shai
On Tue, Oct 19, 2010 at 5:59 PM, Robert Muir
Which would mean all the implementation needs to do is delete its
tokenStream and rename reusableTokenStream to tokenStream, and be done with
it? Works for me !
Also, if we delete reusaleTokenStream, and if the application used the
@override tag, it'll get a compilation error, which will make the
be final in all cases – its defined as decorator pattern, so we enforce
> it). And: You don’t need to make the class itself final, its enough to make
> both methods final.
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
I don't know if this is new, but I've hit this today (on the latest trunk):
junit-sequential:
[junit] Testsuite: org.apache.solr.spelling.DirectSolrSpellCheckerTest
[junit] Testcase:
test(org.apache.solr.spelling.DirectSolrSpellCheckerTest):FAILED
[junit]* fox is not equal to f
and see if i can somehow fix this first, then loop and
> try to reproduce your fail.
>
> On Sun, Nov 28, 2010 at 4:46 AM, Shai Erera wrote:
> > I don't know if this is new, but I've hit this today (on the latest
> trunk):
> >
> > junit-sequential:
> >
Muir wrote:
> > On Sun, Nov 28, 2010 at 6:55 AM, Shai Erera wrote:
> >> Hmm .. I previously ran the test w/ IBM's JDK (6) and after seeing your
> >> mail, I tried w/ Oracle's (6) -- to my surprise the latter succeeds.
> >>
> >> What happens in the
I tried the patch and the test now passes. Thanks !
On Sun, Nov 28, 2010 at 5:07 PM, Robert Muir wrote:
> On Sun, Nov 28, 2010 at 9:55 AM, Uwe Schindler wrote:
> > Hudson is freebsd-jvms-only :(
> >
>
> Right, but in the case of IBM and JRockit, theoretically the IBM JDK
> should work under lin
Uwe, I'm sorry people rushed in to believe I broke backwards ... because I
don't think I did. My only mistake was that I didn't run test-backwards,
'cause I didn't really think anything can break by using CHM and not HM.
fileMap was package-private until two days ago (LUCENE-2778) when I made it
p
Hi
I'd like to discuss the semantics of our API and how backwards tests relate
to it. First, I'd like to confirm my understanding - currently it relates to
3x, but it will apply to 4x after 4.0 will be released:
Public/Protected -- this API is 'public' and we should maintain back-compat,
in the f
Yes, good point - I'll make the member final. And also re-apply my patch
combined w/ yours.
Thanks
Shai
On Tue, Nov 30, 2010 at 9:31 AM, Uwe Schindler wrote:
> --- From: Shai Erera [mailto:ser...@gmail.com] ---
> Uwe, I'm sorry people rushed in to believe I broke backwar
- For tests that simply test some internal apis and nothing else
> important (for plugin compatibility): lets comment out the test. In the bw
> folder we did this with a special comment to leave the code intact.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe S
ng to be difficult - it's
much easier to copy tests over to backwards, then decide which ones should
go there and which shouldn't. Also, adding new API requires a matching
backwards test etc. Not non doable, but difficult - requires discipline.
Shai
On Tue, Nov 30, 2010 at 2:02 PM, Rober
Hi
While IndexWriter declares it accepts a general MP, it will actually fail if
the given instance is not LogMP. So I wonder if we shouldn't consolidate
both of them into one, and pull up all of LMP features to MP. I think all of
LMP's features are useful for any kind of MP, and if someone wants t
things less coupled rather than other way around.
>
> On Thu, Dec 2, 2010 at 12:25, Shai Erera wrote:
> > Hi
> >
> > While IndexWriter declares it accepts a general MP, it will actually fail
> if
> > the given instance is not LogMP. So I wonder if we shouldn't
>
> You can't remove it on 3x, it's used by a host of deprecated methods
> that access LMP's settings through IW.
>
Remove means deprecate in 3x and remove in trunk. Should have been more
clear about that.
For LMP is
> just returns the value of getUseCompoundFile (that is, until Mike's
> patch th
Earwin:
LogMergePolicy.getUseCompoundFile() is a public and not private API on
trunk, not deprecated and used. Perhaps you are talking about something
else?
I'm aware of LUCENE-2773, but still, if you look at LMP's
getUseCompoundFile() in trunk, you'll see it does not factor in the
noCFSRatio set
Opened https://issues.apache.org/jira/browse/LUCENE-2790.
Shai
On Thu, Dec 2, 2010 at 2:22 PM, Earwin Burrfoot wrote:
> On Thu, Dec 2, 2010 at 15:04, Shai Erera wrote:
> > Earwin:
> >
> > LogMergePolicy.getUseCompoundFile() is a public and not private API on
> > tru
e offending tests, because like Uwe says - they
duplicate the test efforts, or we maintain a source for backwards.
I personally am in favor of removing all "non backwards" tests, and keep
those that do actually test backwards behavior. But I know the opinions are
divided here.
Shai
On W
Jumping in late to this thread, though I've read most of it.
As a user and committer, I find the current CHANGES very convenient!
It's very easy for me to read what has changed in 3.0, and very easy
for me to put a CHANGES entry whenever I work on something that
warrants such entry.
And if an iss
Hi
I've hit this:
[junit] Testsuite: org.apache.lucene.search.TestSearchWithThreads
[junit] Testcase:
test(org.apache.lucene.search.TestSearchWithThreads): FAILED
[junit] Some threads threw uncaught exceptions!
[junit] junit.framework.AssertionFailedError: Some threads threw
u
Yes I'm working on a patch
Shai
On Thursday, December 9, 2010, Michael McCandless
wrote:
> On Thu, Dec 9, 2010 at 10:32 AM, Shai Erera wrote:
>> Hi
>>
>> I've hit this:
>>
>> [junit] Testsuite: org.apache.lucene.search.TestSearchW
TestSearchWithThreads failure
>>
>> On Thu, Dec 9, 2010 at 10:32 AM, Shai Erera wrote:
>> > Hi
>> >
>> > I've hit this:
>> >
>> > [junit] Testsuite: org.apache.lucene.search.TestSearchWithThreads
>> > [junit]
Here's the patch:
{code}
Index: lucene/src/test/org/apache/lucene/search/TestSearchWithThreads.java
===
--- lucene/src/test/org/apache/lucene/search/TestSearchWithThreads.java
(revision 1044091)
+++ lucene/src/test/org/apache/lucene/
I see that the test was changed yesterday, and perhaps it causes the
problem? Previously, the test had that code:
// r might have changed because this is not a
// synchronized method. However we don't want
// to make it synchronized to test
Hi
I find it very annoying that I need to set true/false on these methods
whenever I want to control compound files creation. Is it really necessary
to allow writing doc stores in non compound files vs. the other index files
in a compound file? Does somebody know if this feature is used somewhere?
Ok perfect !
Shai
On Thu, Dec 16, 2010 at 11:23 AM, Earwin Burrfoot wrote:
> Incoming LUCENE-2814 drops setUseCompoundDocStore()
>
> On Thu, Dec 16, 2010 at 12:04, Shai Erera wrote:
> > Hi
> >
> > I find it very annoying that I need to set true/false on these met
Hi
Out of curiosity, I searched if we can have a nocommit comment in the code
fail the commit. As far as I see, we try to avoid accidental commits (of say
debug messages) by putting a nocommit comment, but I don't know if "svn ci"
would fail in the presence of such comment - I guess not because we
18, 2010 at 11:56 AM, Uwe Schindler wrote:
> I like this idea, too. But I think we have no control on this, it would be
> as complicated as the mergeprops...
>
> What we have: Hudson halfly hour builds fail when svn contains commits, so
> you see it latest 30 Min later.
>
> U
Hi
I ran the tests on 3x and it failed on the above mentioned test case with
this reproduction line:
ant test-core -Dtestcase=TestConcurrentMergeScheduler
-Dtestmethod=testNoExtraFiles
-Dtests.seed=-1231377766482555904:8173647660289500467
I haven't been able to reproduce it since though, so I gu
pro this too, with the while 1 tester.
> >
> > I'll dig.
> >
> > Mike
> >
> > On Sun, Dec 19, 2010 at 4:55 AM, Shai Erera wrote:
> >> Hi
> >>
> >> I ran the tests on 3x and it failed on the above mentioned test case
&
Hi
I noticed that some tests report threads are left running, even when those
tests never create and start a Thread. Digging deeper I found out that the
tests report "Signal Dispatcher" and "Attach handler" as two threads that
are left running. If I run the test from eclipse, then a "ReaderThread"
I ran the test from both eclipse and Ant, and got similar warnings.
With your patch most of the 'false alarms' do not show up again, but I still
see a strange failure. I add this to after the System.err.print("left thread
running"): System.err.println(Arrays.toString(t.getStackTrace())); -- it
pri
Actually, the MD5 thingy is an attempt to generate a unique temp lock
ID, IIRC. so this piece of code can disappear entirely now that the
tests concurrency is better.
As for the other threads that are left running, I couldn't track down
yet the warning from the benchmark tests, but I'd love to get
igest
> code anymore.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Shai Erera [mailto:ser...@gmail.com]
> > Sent: Saturday, December
n strange
> sophisticated backwards assumptions, just my opinion).
>
>
>
> Uwe
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Shai Erera
Hi
I opened a bug report once (on that ServiceLoader issue - which got fixed
!), but the process wasn't trivial, I'll need to find the instructions how
to do it again :).
Uwe, I run with IBM J9 -- is there a way I can reproduce it locally? Also,
what's the version it happens on (in case you're no
Is there a JIRA issue for it? The patch is large and the issue seems
important enough to be handled through JIRA?
Shai
On Sun, Aug 12, 2012 at 4:53 AM, Robert Muir wrote:
> Here's a patch: http://pastebin.com/PQGSgBtT
>
> On Sat, Aug 11, 2012 at 9:29 AM, Michael McCandless
> wrote:
> > +1
> >
eate JIRAs for these things after the
> fact: but I'm not letting it get in my way.
>
> On Sun, Aug 12, 2012 at 1:13 AM, Shai Erera wrote:
> > Is there a JIRA issue for it? The patch is large and the issue seems
> > important enough to be handled through JIRA?
> >
Looks good.
Perhaps separately, what do you think about doing the same to
Spans.isPayloadAvailable/getPayload?
Shai
On Sun, Aug 12, 2012 at 8:56 AM, Robert Muir wrote:
> Here's a patch: http://pastebin.com/d2DdWxJp
>
> On Sat, Aug 11, 2012 at 1:35 PM, Simon Willnauer
> wrote:
> > +1 this make
>
> On Sun, Aug 12, 2012 at 2:10 AM, Shai Erera wrote:
> > Looks good.
> >
> > Perhaps separately, what do you think about doing the same to
> > Spans.isPayloadAvailable/getPayload?
> >
> > Shai
> >
> >
> > On Sun, Aug 12, 2012 at 8:56 AM, R
I tried to enforce a Timeout using this code, added to my top-level test
case (didn't try yet on LTC):
@Rule
public static Timeout globalTimeout = new Timeout(10); // 100
seconds
This comes straight from JUnit. I don't have the randomizedtesting jar in
my project, so I couldn't add th
Hi
I svn up and ran 'ant test-core', but hit this strange error:
lucene\build.xml:50: The following error occurred while executing this line:
lucene\common-build.xml:1018: The following error occurred while executing
this line:
lucene\common-build.xml:744: report-text doesn't support the
"useSimp
My bad. Mispelled unlock with lock in the finally part ! (so I ended up
locking twice).
Will add a deterministic test commit the fix
Sorry !
Shai
On Tue, May 1, 2012 at 6:46 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:
> Build: https://builds.apache.org/job/Lucene-Solr-tests-o
Committed fix in r1332733.
On Tue, May 1, 2012 at 7:07 PM, Shai Erera wrote:
> My bad. Mispelled unlock with lock in the finally part ! (so I ended up
> locking twice).
>
> Will add a deterministic test commit the fix
>
> Sorry !
>
> Shai
>
> On Tue, May 1, 2
resent (those not accompanied by .sha1 signatures)
> or by building the classpath using ivy (which should simply point to
> the current jar versions, ignoring anything else).
>
> Dawid
>
> On Tue, May 1, 2012 at 5:06 PM, Shai Erera wrote:
> > Hi
> >
> > I svn up a
ed it'd break IDEs (which it
> wouldn't -- you'd just need to run ant resolve afterwards).
>
> Alternatively, there should be a check for lose *.jar (without
> associated *.sha file).
>
> Dawid
>
> On Wed, May 2, 2012 at 11:55 AM, Shai Erera wrote:
> >
these...
>
> Dawid
>
> On Tue, May 1, 2012 at 3:59 PM, Shai Erera wrote:
> > I tried to enforce a Timeout using this code, added to my top-level test
> > case (didn't try yet on LTC):
> >
> > @Rule
> > public static Timeout globalTimeo
Well … we can decide on a list of features we want in 4.0 (e.g., fhe 3
you mention above), estimate the time it would take to finish them and
then give a release date(s). That will get is faster to a release than
if we wait for all JIRA issues to end + the separate branches we work
on.
We should a
Hi
After some discussion on IRC, I'd like to propose we release 3.1 soon. We've
always said we should release more often than we do, and 3x, being the
stable branch, is the perfect candidate. We've created a 3.2 version in
JIRA, and started to re-assign 3.1-marked issues. If you have any issue
you
Hey
Wearing on my rebel hat today, I'd like to propose we drop maven support
from our release process / build system. I've always read about the maven
artifacts never being produced right, and never working (or maybe never is a
too harsh word).
I personally don't understand why we struggle to sup
>
> What does this mean?
>
Jason, it was just my (obviously weird) humor. Let's aim at March 1.
Robert, you're right. I should have written a Lucene/Solr 3.1 release.
Shai
On Sun, Jan 16, 2011 at 7:19 PM, Robert Muir wrote:
> On Sun, Jan 16, 2011 at 11:58 AM, Sha
ved - you don't want
> to do it. I will do the work.
>
> We should not drop Maven support when there are committers willing to
> support it. I obviously count myself in that camp.
>
> Steve
>
> Robert Muir wrote:
>
>
> On Sun, Jan 16, 2011 at 12:03 PM, Shai Er
I don't understand what's so complicated about having an "ant maven" target
in a modules/maven package that generates whatever artifacts are needed. It
can be used by whoever wants to use Maven. Why do we need to "release" those
artifacts? If maven is so important to people, then let's keep it unde
This sounds like incremental field updates :).
Shai
On Mon, Jan 17, 2011 at 1:24 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Sun, Jan 16, 2011 at 11:35 AM, Jason Rutherglen
> wrote:
> >> But: they don't yet support updating the values (the goal is to allow
> >> this, eventua
Out of curiosity, how did the Maven people integrate Lucene before we had
Maven artifacts. To the best of my understanding, we never had proper Maven
artifacts (Steve is working on that in LUCENE-2657).
Shai
On Tue, Jan 18, 2011 at 11:03 AM, Simon Willnauer <
simon.willna...@googlemail.com> wrote
Hi
I ran tests on 3_0 branch and hit this:
[junit] Testcase:
testRankByte(org.apache.lucene.search.function.TestFieldScoreQuery):
Caused an ERROR
[junit] null
[junit] java.util.ConcurrentModificationException
[junit] at
java.util.WeakHashMap$HashIterator.next(WeakHashMap.java:
Hi
Under LUCENE-2720 the index format of both trunk and 3x has changed. You
should re-index any indexes created with either of these code streams.
Shai
Sorry, I intended to take care of it before commit, but forgot :).
I'll fix it now.
Shai
On Sun, Jan 23, 2011 at 11:27 AM, Uwe Schindler wrote:
> Hi Shai,
>
> The Hudson build failures are caused by "nocommits" -- this time not the
> Hudson bug (see recent build logs):
>
> > lucene/dev/trunk/
Hi
Few days ago Robert and I discussed this matter over IRC and thought it's
something we should bring forward to the list. This issue arise due to
recent index format change introduced in LUCENE-2720, and the interesting
question was "if we say 4.0 is required to read all 3x indexes, how would
4.
ves much less efforts :).
Shai
On Mon, Jan 24, 2011 at 3:50 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> +1
>
> Mike
>
> On Mon, Jan 24, 2011 at 8:32 AM, Robert Muir wrote:
> > On Mon, Jan 24, 2011 at 4:07 AM, Shai Erera wrote:
> >> This wi
Hi
This class is used by 'remote' only, and I think it should have been
deprecated (removed in trunk) along with 'remote'. CachingWrapperFilter is
much better. What do you think?
Shai
Neither trunk nor 3x respond, but I suspect it's a general problem ...
Hope it will go up soon (and that's not another attack on Apache infra :)).
Shai
I found what seems to be a "glitch" in StopFilter's ctors -- the boolean
'enablePosInc' was removed from the ctors and users now have to use the
setter instead. However, the ctors do default to 'true' if the passed in
Version is onOrAfter(29).
All of FilteringTokenFilter sub-classes include the en
is MMapDir, LinuxFSDir etc.
Should we fix it on the new branch and go for a second RC?
Shai
On Tue, Mar 8, 2011 at 9:19 AM, Shai Erera wrote:
> I found what seems to be a "glitch" in StopFilter's ctors -- the boolean
> 'enablePosInc' was removed from the ctors and u
What about StopFilter (and LengthFilter) -- should we fix them before 3.1?
Shai
On Tue, Mar 8, 2011 at 4:05 PM, Uwe Schindler wrote:
> I opened https://issues.apache.org/jira/browse/LUCENE-2954
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u.
IWC simplified IW creation - now there is only one ctor, where before there
were multiple ones, and some settings could only be changed after IW was
created.
With IWC, our code is (can become) simpler -- e.g. RAM buffer size, if
specified up front is one thing, but if it's dynamic, we need to have
I agree. After IWC, the only setter left in IW is setInfoStream which makes
sense. But the rest ... assuming these config change don't happen very
often, recreating IW doesn't sound like a big thing to me. The alternative
of complicating IWC to support runtime changes -- we need to be absolutely
su
Can we remove the declaration? The method never throws IOE, but instead
catches it and returns false. I think it's reasonable that such a method
will not throw exceptions.
Shai
throws declaration so that you won't break
> public APIs if this changes implementation.
>
> >
> > On Mon, Mar 21, 2011 at 13:53, Michael McCandless
> > wrote:
> >> On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera wrote:
> >>> Can we remove the decla
Heh -- I think INFRA fixed the subject line thing. Both emails were grouped
together by Gmail. Notice that [Created] and [Updated] in both of them.
Nice !
On Tue, Mar 22, 2011 at 8:58 PM, Doron Cohen (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/LUCENE-2980?page=com.atlassian.
Hi
One of our users stumbled upon what seems to be a bug in trunk (didn't
verify yet against 3x but I have a feeling it exists there as well). The
scenario is: you want to add an index into an existing index. Beforehand,
you want to delete all new docs from the existing index. These are the
operat
I ran tests on 3x today and hit this:
[junit] Testsuite: org.apache.lucene.index.TestIndexWriterMergePolicy
[junit] Testcase:
testMaxBufferedDocsChange(org.apache.lucene.index.TestIndexWriterMergePolicy):
FAILED
[junit]
[junit] junit.framework.AssertionFailedError:
[junit]
Hi
When I run 'ant validate-lucene' on the latest 3x, I get this:
Starting on dir: lucene\lib
WARNING: There may be missing NOTICE files in: lucene\lib. Note, not all
files require a NOTICE. Jar file count: 3 Notice Count: 2
Invalid license: LICENSE for ant-junit-LICENSE.txt
Exception in thread
Renaming to *-ASL on 3x and trunk (as the file indicates it's ASL) resolve
the problem.
Committed to 3x and trunk.
Shai
On Mon, Mar 28, 2011 at 10:57 AM, Shai Erera wrote:
> Hi
>
> When I run 'ant validate-lucene' on the latest 3x, I get this:
>
> Starting on di
mething to do with CMS, because all iterations pass with SMS.
Shai
On Mon, Mar 28, 2011 at 7:00 AM, Shai Erera wrote:
> I ran tests on 3x today and hit this:
>
> [junit] Testsuite: org.apache.lucene.index.TestIndexWriterMergePolicy
> [junit] Testcase:
> testMaxBufferedD
My machine is hot at picking seeds today :).
[junit]
[junit] junit.framework.AssertionFailedError:
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1076)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.
If you're talking about LUCENE-2996, then note that I haven't checked in the
code yet. If you're going to rebuild the artifacts off of
branches/lucene_solr_3_1, I can check in the code there now.
Shai
On Mon, Mar 28, 2011 at 5:04 PM, Robert Muir wrote:
> On Mon, Mar 28, 2011 at 10:54 AM, Uwe Sc
.icu-project.org/trac/ticket/8060
>http://bugs.icu-project.org/trac/ticket/7732
>
> On Mon, Mar 28, 2011 at 10:46 AM, Shai Erera wrote:
> > My machine is hot at picking seeds today :).
> >
> > [junit]
> > [junit] junit.framework.A
If I set tests.iter=X, then the test runs X times, even if an instance of
the test already failed. Would you mind if I change LTC to stop iterating if
a test instance failed? The fix is minor -- add 'if (testsFailed) break;' to
LTC.runChild().
Shai
at 1:38 PM, Robert Muir wrote:
> personally I like the existing behavior for a lot of purposes though.
>
> when i'm trying to write a test for a bug, i use X=100 and look at the
> failure percentage.
>
> On Tue, Mar 29, 2011 at 4:45 AM, Shai Erera wrote:
> > If I set t
Thanks Hoss. This is a good idea. I'll open an issue to track this.
Shai
On Tue, Mar 29, 2011 at 7:11 PM, Chris Hostetter
wrote:
> : I see. On the other hand, it's a bit annoying when you run with X=100 for
> : the purpose of catching a multi-threaded bug, which occurs after the 2nd
> : iteratio
Hi
I noticed that 3.1.0's tag in svn is
http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_1. Should it
not be http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_1_0? At
least, that's what's specified under "Publishing" on ReleaseTodo wiki.
Also, the common-build.xml under t
ut again, +1 on:
* Not releasing 3.1.1, but instead 3.2
* Not branching 3x, but instead only tag it
* Name the artifacts of future releases x.y only.
Shai
On Fri, Apr 1, 2011 at 2:43 PM, Robert Muir wrote:
> On Fri, Apr 1, 2011 at 8:42 AM, Robert Muir wrote:
> > On Fri, Apr 1, 2011 at 8:
H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Steven A Rowe [mailto:sar...@syr.edu]
>> Sent: Friday, April 01, 2011 3:19 PM
>> To: dev@lucene.apache.org
>> Subject: RE:
Thanks !
Shai
On Friday, April 1, 2011, Steven A Rowe wrote:
> Shai, the source jars are available from the maven central repo, e.g.:
>
> http://repo2.maven.org/maven2/org/apache/lucene/lucene-core/3.1.0/lucene-core-3.1.0-sources.jar
>
>> -Original Message-----
&
Hey,
In Lucene 3.1 we've introduced PayloadProcessorProvider which allows you to
rewrite payloads of terms during merge. The main scenario is when you merge
indexes, and you want to rewrite/remap payloads of the incoming indexes, but
one can certainly use it to rewrite the payloads of a term, in a
1 - 100 of 3628 matches
Mail list logo
