to latest and greatest lucene for poor
> corporate users that lost all their data is somewhat overblown.
> Why the heck do you need to upgrade if your app rotted in neglect for
> years??
>
> On Thu, Apr 15, 2010 at 18:14, Erick Erickson
> wrote:
> > Coming in late to the d
>
> On 04/15/2010 10:14 AM, Erick Erickson wrote:
>
>> Coming in late to the discussion, and without really understanding the
>> underlying Lucene issues, but...
>>
>> The size of the problem of reindexing is under-appreciated I think.
>> Somewhere
>> in
Coming in late to the discussion, and without really understanding the
underlying Lucene issues, but...
The size of the problem of reindexing is under-appreciated I think.
Somewhere
in my company is the original data I indexed. But the effort it would take
to
resurrect it is O(unknown). An unfortu
Oops, that'll teach me to just skim things, won't it?
Erick
On Tue, Apr 13, 2010 at 6:14 PM, Andi Vajda 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 someon
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 wrote:
> LOL!
>
> This user is assigned to very old bugzilla issues :-)
>
> -
> Uwe Schindler
>
What kind of JVM settings are you using? Lots of people index lots of
documents
without running into this, can you provide more specifics about your
indexing
settings?
On Tue, Apr 6, 2010 at 10:51 PM, Shivender Devarakonda (JIRA) <
j...@apache.org> wrote:
> java.lang.OutOfMemoryError:Java heap sp
My snap impression is that moving lucene to a sub-tree
under SOLR would introduce some confusion in the minds
of new folks looking at the code. *We* all know that Lucene
stands by itself, but putting it under a solr makes that less
obvious. I claim that there would be questions like "so can
I just
Try +contents:term +contents:query. By misplacing the
'+' you're getting the default OR operator and the '+'
is probably being thrown away by the analyzer.
Luke will help here a lot.
HTH
Erick
On Mon, Mar 15, 2010 at 9:46 AM, christian stadler wrote:
> Hi there,
>
> I have an issue with the Qu
Congrats Chris!
I vote for thinkAboutNotIncludingNormsMaybe(true|false) .
Seriously double negatives are ugly IMO, +1 for changing
Erick
On Fri, Mar 12, 2010 at 12:56 PM, Chris Male (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/LUCENE-2308?page=com.atlassian.jira.plug
Quick side note: The recommended upgrade path is to upgrade to 2.9.latest,
fix all of the deprecation warnings, *then* upgrade to 3.0. The 2.9.X -> 3.0
upgrade just removed all the deprecated stuff.
FWIW
Erick
On Mon, Mar 8, 2010 at 8:51 AM, Ritesh Nigam (JIRA) wrote:
>
>[
> https://iss
ing here.
>
> thanks
> Dyutiman http://old.nabble.com/file/p27756896/IndexUtil.javaIndexUtil.java
>
>
>
>
> Erick Erickson wrote:
> >
> > The very first thing I'd recommend is to get a copy of Luke
> > (google Lucene, Luke) and examine your inde
The very first thing I'd recommend is to get a copy of Luke
(google Lucene, Luke) and examine your index to see if
what you *think* is in there is *actually* in there.
One popular "learning experience" is to do something
like
Document = new Document();
while () {
add field
add field
add d
Tangentially related, but the link on the "how to contribute" page to the
IntelliJ code style file is broken, it reached over into the SOLR Wiki... I
stole the one from SOLR and added it as an attachment and the "how to
contribute" page now links to it
Erick
On Sun, Feb 28, 2010 at 5:14 AM, S
Here are some tantalizing hints. I'll look at this tomorrow if someone
hasn't beaten me to it, but there are *better things I can be doing late
Friday night than messing around with stupid tests* .
>From : http://junit.sourceforge.net/doc/cookbook/cookbook.htm
Once you have tests, you'll want to
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839126#action_12839126
]
Erick Erickson commented on LUCENE-2037:
Uwe:
You were asking about getNam
a single test method, I've always just used the IDE
> > to run individual methods
>
> Right, I've been doing bunches of Solr dev which for me only works
> from the command line... I'm open to suggestions though!
>
> On Fri, Feb 26, 2010 at 10:16 AM, Erick Eri
ethods were tagged w/
> @Before/After,
> > because JUnit would take care running them before/after their
> sub-classes'
> > @Before/After. So that's another win for JUnit4.
> >
> > And of course the @Before/AfterClass are really great !
> > {quote}
> >
> &g
Nice simplification!
On Fri, Feb 26, 2010 at 9:02 AM, wrote:
> Author: uschindler
> Date: Fri Feb 26 14:02:08 2010
> New Revision: 916685
>
> URL: http://svn.apache.org/viewvc?rev=916685&view=rev
> Log:
> LUCENE-2037: Add support for LuceneTestCase.getName() for backwards
> compatibility when re
; Key: LUCENE-2037
> > URL: https://issues.apache.org/jira/browse/LUCENE-2037
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> > Environ
Well, "Things got busy (tm)". Uwe's point if valid; unless there's
demonstrable gain, moving things to Junit4 "just for fun" is wasted motion,
indeed dangerous. I was focusing on LocalizedTestCase to understand the
place of runBare etc. in the scheme of things since when I created
LuceneTestCaseJ4
Hmmm, didn't reopen the JIRA, should I? Or will it just magically get into
Michael's queue?
On Thu, Feb 25, 2010 at 8:52 PM, Erick Erickson wrote:
> < instance field extends that class?>>
> No good reason, I plead confusion when figuring out how to use it. I've
>
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2037:
---
Attachment: LUCENE-2037_remove_testwatchman.patch
Removed unnecessary derivation from
<>
No good reason, I plead confusion when figuring out how to use it. I've
attached a patch to Lucene 2037 that removes the LuceneTestCaseJ4 extending
TestWatchman.
<>
Well, this is to provide the same functionality as LuceneTestCase. I'm
reaching a bit here since I haven't been in that code late
>> the field holding the TestWatchman-subclass). - This is another thing why I
>> am against the migration of our already proven tests.
>>
>>
>>
>> Because of that we don’t want to deprecate LuceneTestCase and instead only
>> transform new tests and such n
OK, never mind
Erick
On Thu, Feb 25, 2010 at 1:48 PM, Earwin Burrfoot wrote:
> My issue is with extra objects created in the process. Field selection
> can be handled with, well, FieldSelector.
>
> 2010/2/25 Erick Erickson :
> > Does LazyLoading address this? I'm
Junit4:
Well, simply disliking the @Test annotation seems like a poor reason to stay
with Junit3, although I admit it's a pain in the neck to change. Which is
why I didn't try to change all of them. The current system lends itself to
the practice of mangling the test name as a way of not running i
I'm so glad somebody else gets bugged by all the trivial warnings, all along
I thought it was a personal problem ..
As I remember, I deprecated LuceneTestCase entirely to encourage people
to migrate to the Junit4 variant (LuceneTestCaseJ4). So removing those
deprecations should be approached with
Does LazyLoading address this? I'm assuming your issue is
that the default behavior loads the entire document regardless
of whether you actually want all the fields.
Erick
On Thu, Feb 25, 2010 at 7:52 AM, Earwin Burrfoot wrote:
> I'm thinking, should Lucene introduce new interface to read s
Please repost this over on the users list. This list is for internal
development discussions.
Thanks
Erick
On Sat, Jan 23, 2010 at 9:56 PM, jchang wrote:
>
> By the way: this happens with a brand new directory with no files at all in
> it.
>
>
> jchang wrote:
> >
> > When I try to start my
Could I ask you to re-post this on the java user's list? This list is for
*internal* Lucene development discussion.
Thanks
Erick
On Fri, Jan 15, 2010 at 8:28 AM, Altimatic wrote:
>
> Hi All,
>
> I have an application that has to count the frequency that a specific
> regular expression is matched
I once knew of a math prof in the early days of electronic
book submissions who had a helpful person change all the
"iff"s into "if" thinking they were all typo's... in all the proofs
in a math text... As his fellow faculty member was relaying
the story added "putting them back was non-trivial"
[
https://issues.apache.org/jira/browse/LUCENE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794471#action_12794471
]
Erick Erickson commented on LUCENE-2122:
Robert:
Where are we on this? La
d then asserting expected
> results.
> I don't see any obvious problem though, just thinking if something based on
> the 'current time' was affecting the tests, then this might make it hard to
> reproduce.
>
>
> On Sat, Dec 12, 2009 at 9:26 PM, Erick Erickson
&
and see if we get more random-hard-to-reproduce failures.
>
>
> On Mon, Dec 14, 2009 at 1:46 PM, Erick Erickson
> wrote:
>
>> Oooh, nice...
>>
>>
>> On Mon, Dec 14, 2009 at 1:26 PM, wrote:
>>
>>> Author: rmuir
>>> Date: Mon Dec 14
Oooh, nice...
On Mon, Dec 14, 2009 at 1:26 PM, wrote:
> Author: rmuir
> Date: Mon Dec 14 18:26:26 2009
> New Revision: 890427
>
> URL: http://svn.apache.org/viewvc?rev=890427&view=rev
> Log:
> LUCENE-2155: add assertion to check if something changes default locale
> behind our back when using Lo
I was running the whole ant-clean-test in a loop last night for
LUCENE-2122 and had this error in IndexWriter occur once
in 30+ runs. I now there has been some work on spurious
failures here lately and thought I'd add this on the chance
it'd help anyone tracking this issue. Didn't see a JIRA...
I
es not
> get the answer). If you answer only on the ML, we loss those comments in the
> issue.
>
>
>
> Uwe
>
>
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> -
NE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> >Reporter: Erick Erickson
> >Priority: Minor
> > Fix For: 3.1
> >
&g
-
> >
> > Key: LUCENE-2122
> > URL: https://issues.apache.org/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >
This type of question is not appropriate on the developers list, this
list is devoted to development. Please please post this kind of
question on the user's list.
As it happens, this very topic is being discussed under a thread
"Recover special terms from StandardTokenizer", that should give
you s
een one before with the old LocalizedTestCase (as the
> behavior is the same, we are changing a system-wide static)
>
> The only small difference is that this happens @BeforeClass with the new
> one, versus @Before with the old one?
>
>
> On Fri, Dec 11, 2009 at 9:05 AM, Erick Erick
So I ran this test suite from Idea a dozen times or so and no problem.
Then I ran it a couple of thousand times through Ant via a shell
script. No problem.
So I'm tending toward thinking it's an Eclipse issue, what do
you think?
Erick
On Thu, Dec 10, 2009 at 4:23 PM, Erick Eric
mehow there is some race, and the default locale
> is actually changing as the test is running, or something crazy like this?!
>
>
>
> On Thu, Dec 10, 2009 at 3:23 PM, Erick Erickson
> wrote:
>
>> Yep, that sure makes me nervous too. I've never seen a failure in Inte
URL: https://issues.apache.org/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> >Reporter: Erick Erickson
> >As
Mike:
Which of these do you think this patch *should* address before committing?
Just the last two?
As many as Christian has energy for ?
On Thu, Dec 10, 2009 at 12:24 PM, Michael McCandless (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/LUCENE-2133?page=com.atlassian.jira.plugi
rg/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> >Reporter: Erick Erickson
> >Assignee: Robert Muir
> >Prio
[
https://issues.apache.org/jira/browse/LUCENE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2122:
---
Attachment: LUCENE-2122-r4.patch
OK, I plead advanced senility or some other excuse for the
/issues.apache.org/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> >Reporter: Erick Erickson
> >Assignee: Erick Erickson
> >
Does someone with commit rights want to pick this up? I've incorporated the
changes suggested by Robert (Thanks!) and think it's ready to go.
Erick
[
https://issues.apache.org/jira/browse/LUCENE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2122:
---
Attachment: LUCENE-2122-r3.patch
Made LocalizedTestCase abstract...
> Use JUn
rent locales... just one
> of those things
>
> thanks for tackling this one
>
>
> On Sun, Dec 6, 2009 at 8:30 PM, Erick Erickson wrote:
>
>> I just made a comment on how many times
>> I've made the "that looks unnecessary, I'll
>> take it out" mi
ttps://issues.apache.org/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >Affects Versions: 3.1
> >Reporter: Erick Erickson
> >Assignee: Erick Erickson
[
https://issues.apache.org/jira/browse/LUCENE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2122:
---
Attachment: LUCENE-2122-r2.patch
Restoring original default Locale after test class has
> >
> > Key: LUCENE-2122
> > URL: https://issues.apache.org/jira/browse/LUCENE-2122
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
...
Erick
On Sun, Dec 6, 2009 at 6:45 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Sun, Dec 6, 2009 at 5:51 PM, Uwe Schindler wrote:
> >> On Sun, Dec 06, 2009 at 05:31:53PM -0500, Erick Erickson wrote:
> >> > This may be a silly question, and I
This may be a silly question, and I admit that I haven't looked a the code,
but was there a good reason to +1 it in the first place or was that just
paranoia
to prevent off-by-one errors? If there *was* a valid reason, might it make
sense to +1 min(nDocs, maxDoc())?
Erick
On Sun, Dec 6, 2009 at
[
https://issues.apache.org/jira/browse/LUCENE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2122:
---
Attachment: LUCENE-2122.patch
All tests pass. This modifies all test classes (core and
/LUCENE-2122
Project: Lucene - Java
Issue Type: Improvement
Components: Other
Affects Versions: 3.1
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Fix For: 3.1
Use the @Parameterized capabilities
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2037:
---
Attachment: LUCENE-2037.patch
Had enough time this morning to reconcile this with Kay Kay&#
[
https://issues.apache.org/jira/browse/LUCENE-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned LUCENE-2096:
--
Assignee: (was: Erick Erickson)
Maybe for later
> Investigate parallelizing
. But we can probably revisit them subsequently. Please review
> > them to serve as a starting point for the same.
> >
> >
> > Erick Erickson wrote:
> >>
> >> Mike:
> >>
> >> I should be able to create a new 2037 patch pretty easily if
Mike:
I should be able to create a new 2037 patch pretty easily if you
want to apply 2065 first. Let me know
Erick
On Thu, Dec 3, 2009 at 9:05 PM, Kay Kay wrote:
> Mike -
> I have attached another patch to LUCENE-2065 , in sync with the trunk now.
>
>
>
>
>
t; not get src/test converted in.
>
> In any case , if you were comitting this one (2037) to trunk , may be I
> can wait before creating the patch again.
>
>
>
>
> Erick Erickson wrote:
>
>> I didn't realize 2065 had already been down this path, thought
>
g the rest, so I'll wait for
these two patches to be applied before looking back at it...
Not to mention the Localized test thing.
Erick
On Thu, Dec 3, 2009 at 5:57 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Thu, Dec 3, 2009 at 5:48 PM, Erick Erickson
>
ype: Improvement
> > Components: Other
> >Affects Versions: 3.1
> > Environment: Development
> >Reporter: Erick Erickson
> >Assignee: Michael McCandless
> >Priority: Minor
> > Fix For: 3.1
&g
Is anyone thinking about committing this patch? And/or what do I need to
do/should have done to indicate it's ready for review?
Poor lonely patch, sitting out there all alone and neglected ...
Erick
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783442#action_12783442
]
Erick Erickson commented on LUCENE-2037:
Darn it! I'll get the comme
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2037:
---
Attachment: LUCENE-2037.patch
See JIRA comments
> Allow Junit4 tests in our environm
[
https://issues.apache.org/jira/browse/LUCENE-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783436#action_12783436
]
Erick Erickson commented on LUCENE-2096:
Parallelizing tests is proving tric
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Ant Contrib has a "ForEach" construct that may speed up running all of the
Junit tests by parallelizing them with a configurable number of threads. I
envision this in several stages. Fir
ong
to whoever wants to give it a spin and we'll get a clue whether
it provides enough of an improvement to pursue seriously.
I'll open a JIRA since at least Mike and I seem to be interested
Erick
On Fri, Nov 27, 2009 at 1:27 PM, Michael McCandless <
luc...@mikemccandless.com>
and I'll open a JIRA and take it on. For the
benefit of those aforementioned *real* people with *real*
machines, who I'll rely upon to help test this notion
Is the poor-mans version of this on a dual-core machine
just running "test-core" and "test-contrib" in two sep
ractive testing".
>>
>> Plus, this is an ongoing goal with time, not a one-time event. As we
>> create tests we should generally try to maximize coverage and minimize
>> CPU cost, as long as the effort is smallish.
>>
>> Mike
>>
>> On Wed, Nov 25,
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782916#action_12782916
]
Erick Erickson commented on LUCENE-2037:
Hold off on this patch until I g
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782915#action_12782915
]
Erick Erickson commented on LUCENE-1844:
OK, fire when ready Gridley. Pretty
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-1844:
---
Attachment: LUCENE-1844-Junit3.patch
Speeds up TestBooleanMinShouldMatch and
I posted a rather long diatribe outlining why I think speed-ups
are a false goal for Lucene. Briefly, I'm convinced that as long
as the tests are run when Hudson builds Lucene, 99% of the
value of unit tests is realized. I suppose this implies that the
hard-core committers agree that as long as fai
IMHO there are other reasons to upgrade to junit4 besides
parallelization, there are some nice new capabilities. I
suppose the analogous question is "why upgrade to
Lucene 2.9?"
Especially since it's not a matter of upgrading. Junit3 tests run
just fine under junit4. I've tested after removing the
allel by hand essentially.
> No ant task to help with this last I looked. So it will probably end up
> being an alternate way to run the tests initially (at best).
>
> - Mark
>
> Erick Erickson wrote:
> > They're ready to go, but at Uwe's suggestion, I've been
They're ready to go, but at Uwe's suggestion, I've been waiting for 3.0 to
get settled before prompting someone to apply this patch. I was going to
generate a new patch for this and for 2037 (junit4 tests) just to make sure
they were easy to apply. But if you're willing, the patches are already
att
Agreed, annoying. Haven't found any solution either.
Erick
On Wed, Nov 25, 2009 at 7:51 AM, Uwe Schindler wrote:
> I would like to have a link to the patch/file/... in the mail about an
> update to the attached files. This is also annoying.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28
[
https://issues.apache.org/jira/browse/LUCENE-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781716#action_12781716
]
Erick Erickson commented on LUCENE-2092:
Well, if it's been there sinc
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780368#action_12780368
]
Erick Erickson commented on LUCENE-2037:
Well, last night I cha
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779530#action_12779530
]
Erick Erickson commented on LUCENE-2037:
{quote}
Yes, I do feel we should
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779492#action_12779492
]
Erick Erickson commented on LUCENE-2037:
Frankly, I don't see how that w
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779491#action_12779491
]
Erick Erickson commented on LUCENE-2037:
I think you're mis-reading this
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779449#action_12779449
]
Erick Erickson commented on LUCENE-2037:
I was thinking more a
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779251#action_12779251
]
Erick Erickson commented on LUCENE-2037:
Well, it all depend on how you
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> --
>
> *From:* Erick Erickson [mailto:erickerick...@gmail.com]
> *Sent:* Monday, November 16, 2009 7:10 PM
> *To:* java-dev@lucene
projects and want a
> clean API. People needing backwards compatibility can use 2.9.1, but support
> for that version will be cancelled in future and bugfixes will only go into
> 3.x.
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> e
One of my "specialties" is asking obvious questions just to see if
everyone's assumptions
are aligned. So with the discussion about branching 3.0 I have to ask "Is
there going to
be any 3.0 release intended for *production*?". And if not, would we save a
lot of work
by just not worrying about retro
Improvement
> > Components: Other
> >Affects Versions: 3.1
> > Environment: Development
> >Reporter: Erick Erickson
> >Assignee: Erick Erickson
> >Priority: Minor
> > Fix For: 3.1
> >
> > A
> >
> > Key: LUCENE-2037
> > URL: https://issues.apache.org/jira/browse/LUCENE-2037
> > Project: Lucene - Java
> > Issue Type: Improvement
> > Components: Other
> >
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-1844:
---
Attachment: LUCENE-1844.patch
Saves 3-4 minutes overall. Arbitrarily limited the
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-1844:
---
Attachment: (was: LUCENE-1844.patch)
> Speed up junit te
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-1844:
---
Attachment: LUCENE-1844.patch
This supersedes the first patch I submitted. Apply after
[
https://issues.apache.org/jira/browse/LUCENE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-1844:
---
Attachment: (was: LUCENE-1844.patch)
> Speed up junit te
[
https://issues.apache.org/jira/browse/LUCENE-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-2037:
---
Attachment: junit-4.7.jar
LUCENE-2037.patch
LuceneTestCaseJ4 should replace
25 PM, Erick Erickson wrote:
> OK thanks for adding me to the ACL. I'll have it tomorrow sometime. Does
> anyone object to deprecating LuceneTestCase with notations to use
> LuceneTestCaseJ4?
>
> I tried two approaches, both work. Both allow you to use LuceneTestCaseJ4
> rat
OK thanks for adding me to the ACL. I'll have it tomorrow sometime. Does
anyone object to deprecating LuceneTestCase with notations to use
LuceneTestCaseJ4?
I tried two approaches, both work. Both allow you to use LuceneTestCaseJ4
rather than LuceneTestCase as a superclass, with the caveat you hav
1 - 100 of 131 matches
Mail list logo
