Build failed in Hudson: Lucene-trunk #691

See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/691/changes

Changes:

[otis] - Small documentation mods.

[ryan] LUCENE-1503 -- refactor spatial Query/Filter classes

[ryan] LUCENE-1387 -- adding locallucene as new spatial contrib package.

------------------------------------------
[...truncated 5757 lines...]

javacc-notice:

jflex-uptodate-check:

jflex-notice:

common.init:

build-lucene:

build-lucene-tests:

init:

clover.setup:

clover.info:

Build failed in Hudson: Lucene-trunk #692

See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/692/changes

------------------------------------------
[...truncated 5758 lines...]

javacc-notice:

jflex-uptodate-check:

jflex-notice:

common.init:

build-lucene:

build-lucene-tests:

init:

clover.setup:

clover.info:

clover:

compile-core:

jar-src:
      [jar] Building jar:
http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/contrib/misc/lucene-misc-2.4-SNAPSHOT-src.jar 

Re: Build failed in Hudson: Lucene-trunk #692

Re: Build failed in Hudson: Lucene-trunk #692

On 1/1/09 6:28 AM, Michael McCandless wrote:
>
> I think the pom.xml.template under contrib/spatial is broken (looks 
> like a copy from contrib/instantiated), which is then causing 
> dist-maven task to fail with this error:
>
> Error deploying artifact: File 
>
/export/home/hudson/hudson-slave/workspace/Lucene-trunk/trunk/build/contrib/spatial/lucene-instantiated-2.4-SNAPSHOT.jar 
> does not exist
>
> I'm not familiar w/ Maven/pom.xml.template... likely we can just 
> replace "instantiated" with "spatial"?
>
>
Yes that will do the trick. I just committed the change. The next build 
should be successful.

-Michael

[jira] Commented: (LUCENE-1501) Phonetic filters

    [
https://issues.apache.org/jira/browse/LUCENE-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660196#action_12660196
] 

Karl Wettin commented on LUCENE-1501:
-------------------------------------

bq. Ryan McKinley - 30/Dec/08 10:36 AM
bq. FYI, solr includes phonetic filters also... perhaps we should consolidate?

Ah, yes I think we should. I'll take a look at how they differ.

> Phonetic filters
> ----------------
>
>                 Key: LUCENE-1501
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1501
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: contrib/*
>            Reporter: Karl Wettin
>            Assignee: Karl Wettin
>            Priority: Minor
>         Attachments: LUCENE-1501.txt
>
>
> Metaphone, double metaphone, soundex and refined soundex filters using commons codec API.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Build failed in Hudson: Lucene-trunk #692

On Jan 1, 2009, at 7:05 AM, Michael Busch wrote:

>
>
> On 1/1/09 6:28 AM, Michael McCandless wrote:
>>
>> I think the pom.xml.template under contrib/spatial is broken (looks  
>> like a copy from contrib/instantiated), which is then causing dist- 
>> maven task to fail with this error:
>>
>> Error deploying artifact: File /export/home/hudson/hudson-slave/ 
>> workspace/Lucene-trunk/trunk/build/contrib/spatial/lucene- 
>> instantiated-2.4-SNAPSHOT.jar does not exist
>>
>> I'm not familiar w/ Maven/pom.xml.template... likely we can just  
>> replace "instantiated" with "spatial"?
>>
>>
> Yes that will do the trick. I just committed the change. The next  
> build should be successful.
>

thanks.  sorry about that.

ryan

[jira] Commented: (LUCENE-1483) Change IndexSearcher to use MultiSearcher semantics for multiple subreaders

    [
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660217#action_12660217
] 

Mark Miller commented on LUCENE-1483:
-------------------------------------

Alright, my new years gift to myself is going to be to work on this a bit.

I've got part of the straight ord problem - if multiple queue entries clashed on conversion, and they were
indeed not just clashes but clashes with the same oringal value, they were still getting an incremented
subord when they should get an identical subord. So I've taken care of that, but something still fails. Looking.

On a side note though, we probably want another straight ords comparator that does not fall back to subords.
Then we can use that as the first comparator on a large segment, and equal values wont have to needlessly
fallback to subords for a worthless 0 on 0 check.

> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
>                 Key: LUCENE-1483
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1483
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.9
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, sortBench.py, sortCollate.py
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing for individual segment
reloading on reopen.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (LUCENE-1483) Change IndexSearcher to use MultiSearcher semantics for multiple subreaders

    [
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660226#action_12660226
] 

Mark Miller commented on LUCENE-1483:
-------------------------------------

Cool, got the other one. When copying the doc into a slot (FieldComparator.copy), the subord had to be set to
0 so that it didnt retain a stale value. Straight ord looks good now as do the rest, so I'll try and get a custom
comparator policy in there so we can benchmark a couple strategies.

Rather than a new Comparator for a pure ord that doesnt fall to subord, perhaps the policy could return an
overridden straight ord if its first and on the first index reader...

> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
>                 Key: LUCENE-1483
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1483
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.9
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, sortBench.py, sortCollate.py
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing for individual segment
reloading on reopen.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LUCENE-1483) Change IndexSearcher to use MultiSearcher semantics for multiple subreaders

     [
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated LUCENE-1483:
--------------------------------

    Attachment: LUCENE-1483.patch

Still pretty ugly, but this patch has a working ord I think, allows readers in any order (giving largest to
smallest now), and has a hackey ComparatorPolicy that can alter the comparators being used. Right now
there is an ugly little one for ORD that switches to ORD_DEM after the first segment. The rest just use the
same comparator throughout.

Also added something we may take out - an option to not fill fields (which we cant use for back compat, but a
user could). If you are not using a MultiSearcher, its kind of a waste of time to fill fields.

Much to do, but fully functional I think.

> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
>                 Key: LUCENE-1483
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1483
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.9
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
LUCENE-1483.patch, sortBench.py, sortCollate.py
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing for individual segment
reloading on reopen.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: running "ant test" with multiple threads/processes?

: Has anyone explored ways to have "ant test" take advantage of concurrency?
: Since each JUnit test source (TestXXX.java) is independent, this should be
: possible.
: I'd love to have "ant test test-tag" run faster on an N-core machine.

I've see some attempts at a generalized solution to this in the past, but 
none of them ever seemed to successful.

manually spliting tests up into buckets and running <parallel> <junit> 
tasks for each bucket tends to be the approach many projects take.  in our 
case the first quick win might be to just add a new attribute to the 
contrib-crawl macro that says wether it can be parallelized or not, 
and then replace the <sequential> task with a <parallel threadCount="..."> 
task (use a threadCount="1" for things contrib-crawls that can't be 
parallelized)

test-contrib and javadocs-contrib should be parallelizable, but 
build-contrib won't be (since some contribs depend on other contribs)

that should help some ... but if you really want to parallelize test-core, 
we would need to hardcode some N <junit> calls each containing a filset 
(although with some creativity we could probably dynamicly divide the 
tests up into N filesets using things like the <sort>, <first> and 
<restrict> resource collections)

-Hoss