date:20110912

[
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102458#comment-13102458
]

Dawid Weiss commented on LUCENE-3429:
-

I wrote that snippet yesterday as a proof of concept - it is simple and I think
does the job (you can control timeouts of all tests of a class, a single test's
timeout time or, in case of Lucene, global timeouts on all tests simply by
putting the rule in the superclass of all tests).

In fact, JUnit4 already has two built-in options for doing timeouts: a @Timeout
rule much like mine (but not logging object's internal fields) and
@Test(timeout=...). My implementation simple expands on this by adding a live
dump of objects being tested (important in case of live fields) -- sending a
signal (or ctrl-break combination on windows) will dump the spinning test's
fields to the console.

I can prepare a patch, but it's actually trivial to just take the rule's code
from github and paste in LuceneTestCase. Should work out of the box, perpahs
with changes related to the fact that I used commons-lang for dumping the
target object and we may simply restrict it to dumping the current seed.

improve build system when tests hang

Key: LUCENE-3429
URL: https://issues.apache.org/jira/browse/LUCENE-3429
Project: Lucene - Java
Issue Type: Test
Reporter: Robert Muir
Fix For: 3.5, 4.0

Attachments: LUCENE-3429.patch

Currently, if tests hang in hudson it can go hung for days until we manually
kill it.
The problem is that when a hang happens its probably serious, what we want to
do (I think), is:
# time out the build.
# ensure we have enough debugging information to hopefully fix any hang.
So I think the ideal solution would be:
# add a sysprop -D that LuceneTestCase respects, it could default to no
timeout at all (some value like zero).
# when a timeout is set, LuceneTestCase spawns an additional timer thread for
the test class? method?
# if the timeout is exceeded, LuceneTestCase dumps all thread/stack
information, random seed information to hopefully reproduce the hang, and
fails the test.
# nightly builds would pass some reasonable -D for each test.
separately, I think we should have an ant-level timeout for the whole
build, in case it goes completely crazy (e.g. jvm completely hangs or
something else), just as an additional safety.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3396) Make TokenStream Reuse Mandatory for Analyzers

2011-09-12 Thread Chris Male (JIRA)


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

Chris Male updated LUCENE-3396:
---

Attachment: LUCENE-3396-forgotten.patch

During the merging of changes I lost some conversions of some test Analyzers.

Patch addresses them (including the unholy TestPayloads).

 Make TokenStream Reuse Mandatory for Analyzers
 --

 Key: LUCENE-3396
 URL: https://issues.apache.org/jira/browse/LUCENE-3396
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Chris Male
 Attachments: LUCENE-3396-forgotten.patch, LUCENE-3396-rab.patch, 
 LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, 
 LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, LUCENE-3396-rab.patch


 In LUCENE-2309 it became clear that we'd benefit a lot from Analyzer having 
 to return reusable TokenStreams.  This is a big chunk of work, but its time 
 to bite the bullet.
 I plan to attack this in the following way:
 - Collapse the logic of ReusableAnalyzerBase into Analyzer
 - Add a ReuseStrategy abstraction to Analyzer which controls whether the 
 TokenStreamComponents are reused globally (as they are today) or per-field.
 - Convert all Analyzers over to using TokenStreamComponents.  I've already 
 seen that some of the TokenStreams created in tests need some work to be 
 reusable (even if they aren't reused).
 - Remove Analyzer.reusableTokenStream and convert everything over to using 
 .tokenStream (which will now be returning reusable TokenStreams).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: How to see links in offline mode?

2011-09-12 Thread Simon Willnauer

On Mon, Sep 12, 2011 at 7:10 AM, ahmad ajiloo ahmad.aji...@gmail.com wrote:
 Hello
 I'm using Nutch to crawl in web. then send my data to Solr for index and
 search. when Solr search on indexes, the url of hints, which Solr finds, is
 linked to the web. But I want to have some titles which linked to my site.
 so I want to use crawled data in Nutch database to show any web pages or
 files that users search in my search engine! this is an offline search and
 our users wouldn't need to go on other web pages.

 can you help me?

hey, this is the lucene developmen mailing list. you should get better
help on the nutch user list -
http://nutch.apache.org/mailing_lists.html

simon


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Simon Willnauer

+1 Changes look fine, tests work I beasted them for a couple of hours.

thanks mike!

On Mon, Sep 12, 2011 at 6:20 AM, Shai Erera ser...@gmail.com wrote:
 +1 to release. Checked docs and changes and they look ok.

 Shai

 On Mon, Sep 12, 2011 at 1:57 AM, Michael McCandless
 luc...@mikemccandless.com wrote:

 +1 to release.

 I ran the release smoke tester, it was happy!

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Sep 9, 2011 at 12:06 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
  Please vote to release the RC1 artifacts at:
 
 
   https://people.apache.org/~mikemccand/staging_area/lucene-solr-3.4.0-RC1-rev1167142
 
  as Lucene 3.4.0 and Solr 3.4.0.
 
  Mike McCandless
 
  http://blog.mikemccandless.com
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3396) Make TokenStream Reuse Mandatory for Analyzers

2011-09-12 Thread Chris Male (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102508#comment-13102508
 ] 

Chris Male commented on LUCENE-3396:


Committed revision 1169654.

 Make TokenStream Reuse Mandatory for Analyzers
 --

 Key: LUCENE-3396
 URL: https://issues.apache.org/jira/browse/LUCENE-3396
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Reporter: Chris Male
 Attachments: LUCENE-3396-forgotten.patch, LUCENE-3396-rab.patch, 
 LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, 
 LUCENE-3396-rab.patch, LUCENE-3396-rab.patch, LUCENE-3396-rab.patch


 In LUCENE-2309 it became clear that we'd benefit a lot from Analyzer having 
 to return reusable TokenStreams.  This is a big chunk of work, but its time 
 to bite the bullet.
 I plan to attack this in the following way:
 - Collapse the logic of ReusableAnalyzerBase into Analyzer
 - Add a ReuseStrategy abstraction to Analyzer which controls whether the 
 TokenStreamComponents are reused globally (as they are today) or per-field.
 - Convert all Analyzers over to using TokenStreamComponents.  I've already 
 seen that some of the TokenStreams created in tests need some work to be 
 reusable (even if they aren't reused).
 - Remove Analyzer.reusableTokenStream and convert everything over to using 
 .tokenStream (which will now be returning reusable TokenStreams).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2749) use BoundaryScanner in Solr FVH

2011-09-12 Thread Koji Sekiguchi (JIRA)


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

Koji Sekiguchi updated SOLR-2749:
-

Attachment: SOLR-2749.patch

Draft, halfway patch.

 use BoundaryScanner in Solr FVH
 ---

 Key: SOLR-2749
 URL: https://issues.apache.org/jira/browse/SOLR-2749
 Project: Solr
  Issue Type: New Feature
  Components: highlighter
Reporter: Koji Sekiguchi
Priority: Minor
 Attachments: SOLR-2749.patch


 After LUCENE-1824 committed, Solr FragmentsBuilder can snip off at the 
 natural boundary by nature. But to bring out the full feature, Solr should 
 take care of arbitrary BoundaryScanner in solrconfig.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: How to serach on specific file types ?

2011-09-12 Thread Jan Høydahl

Hi,

You have asked a user question on the Developers mailing list. Please ask it 
again on the solr-user list, and make sure to include a LOT of more context 
if you want a good answer. Reading through 
http://wiki.apache.org/solr/UsingMailingLists first is a good place to start.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

On 12. sep. 2011, at 06:53, ahmad ajiloo wrote:

 Hello
 I want to search on articles. So need to find only specific files like doc, 
 docx, and pdf. can you help me?

[jira] [Commented] (SOLR-1979) Create LanguageIdentifierUpdateProcessor

2011-09-12 Thread Markus Jelsma (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102520#comment-13102520
 ] 

Markus Jelsma commented on SOLR-1979:
-

Hi Jan,

Can we also use the mapping feature without detection? Our detection is done in 
a Nutch cluster so we already identified many millions of docs.

Thanks

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Martijn v Groningen

+1 All tests passed on my machine.
The Lucene release notes do contain some old highlights like join
module. I assume this will be removed, right?

On 12 September 2011 09:03, Simon Willnauer
simon.willna...@googlemail.com wrote:
 +1 Changes look fine, tests work I beasted them for a couple of hours.

 thanks mike!

 On Mon, Sep 12, 2011 at 6:20 AM, Shai Erera ser...@gmail.com wrote:
 +1 to release. Checked docs and changes and they look ok.

 Shai

 On Mon, Sep 12, 2011 at 1:57 AM, Michael McCandless
 luc...@mikemccandless.com wrote:

 +1 to release.

 I ran the release smoke tester, it was happy!

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Sep 9, 2011 at 12:06 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
  Please vote to release the RC1 artifacts at:
 
 
   https://people.apache.org/~mikemccand/staging_area/lucene-solr-3.4.0-RC1-rev1167142
 
  as Lucene 3.4.0 and Solr 3.4.0.
 
  Mike McCandless
 
  http://blog.mikemccandless.com
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org





-- 
Met vriendelijke groet,

Martijn van Groningen

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Shalin Shekhar Mangar

+1

All tests pass on Linux 32-bit, 64-bit and Mac.

On Fri, Sep 9, 2011 at 9:36 PM, Michael McCandless 
luc...@mikemccandless.com wrote:

 Please vote to release the RC1 artifacts at:


 https://people.apache.org/~mikemccand/staging_area/lucene-solr-3.4.0-RC1-rev1167142

 as Lucene 3.4.0 and Solr 3.4.0.

 Mike McCandless

 http://blog.mikemccandless.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-- 
Regards,
Shalin Shekhar Mangar.

where is the SOLR_HOME

2011-09-12 Thread ahmad ajiloo

Hi
In this 
pagehttp://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.ICUTokenizerFactorysaid:
Note: to use this filter, see solr/contrib/analysis-extras/README.txt for
instructions on which jars you need to add to your SOLR_HOME/lib 
I can't find SOLR_HOME/lib !
Is there: apache-solr-3.3.0\example\solr ? there is no directory which
name is lib
or: apache-solr-3.3.0\ ? there is no directory which name is lib

or : apache-solr-3.3.0\example ? there is a lib directory. I copied 4
libraries exist in solr/contrib/analysis-extras/ to 
apache-solr-3.3.0\example\lib but some errors exist in loading page 
http://localhost:8983/solr/admin; like:
*org.apache.solr.common.SolrException: Error loading class
'solr.ICUNormalizer2FilterFactory' 

*thanks a lot*
*

[jira] [Commented] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


[ 
https://issues.apache.org/jira/browse/SOLR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102573#comment-13102573
 ] 

Jan Høydahl commented on SOLR-1979:
---

@Markus: Sure. If you put your pre-known language code in the same field 
configured in langid.langField and use langid.overwrite=false, you will obtain 
that behavior.

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1979) Create LanguageIdentifierUpdateProcessor

2011-09-12 Thread Markus Jelsma (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102578#comment-13102578
 ] 

Markus Jelsma commented on SOLR-1979:
-

Hi. This is not what i understood from reading the wiki doc. Will the update 
processor skip detection with these settings? It's rather costly on many docs.

Anyway, this is great work already, thanks!

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: where is the SOLR_HOME

2011-09-12 Thread Erik Hatcher

Yes, SOLR_HOME in this case, if you're running the example application, in 
example/solr.  There's no lib/ directory there by default, just create it 
yourself.

You can also add lib directives in your solrconfig.xml (you'll see this 
documented in comments in the example config).

Erik



On Sep 12, 2011, at 07:51 , ahmad ajiloo wrote:

 Hi
 In this page said:
 Note: to use this filter, see solr/contrib/analysis-extras/README.txt for 
 instructions on which jars you need to add to your SOLR_HOME/lib 
 I can't find SOLR_HOME/lib !
 Is there: apache-solr-3.3.0\example\solr ? there is no directory which name 
 is lib
 or: apache-solr-3.3.0\ ? there is no directory which name is lib
 
 or : apache-solr-3.3.0\example ? there is a lib directory. I copied 4 
 libraries exist in solr/contrib/analysis-extras/ to 
 apache-solr-3.3.0\example\lib but some errors exist in loading page 
 http://localhost:8983/solr/admin; like:
 org.apache.solr.common.SolrException: Error loading class 
 'solr.ICUNormalizer2FilterFactory' 
 
 thanks a lot
 
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


[ 
https://issues.apache.org/jira/browse/SOLR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102646#comment-13102646
 ] 

Jan Høydahl commented on SOLR-1979:
---

Yep, it will skip detection if the field defined in langid.langField is not 
emtpty and langid.overwrite==false

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


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

Jan Høydahl updated SOLR-1979:
--

Attachment: SOLR-1979.patch

Patch updated to fit new directory structure, updated comments to point to Wiki 
doc.

Also optimized regex, now pre-compiling patterns instead of using 
String.replace directly.

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


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

Jan Høydahl updated SOLR-1979:
--

Attachment: SOLR-1979.patch

New patch with these improvements:

* Now also allows config at first level, without lst name=default
* Added langid to example schema (commented out), so it is really easy to 
demonstrate

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #238: POMs out of sync

2011-09-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/238/

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.embedded.TestSolrProperties.testProperties

Error Message:


Stack Trace:
java.lang.AssertionError: 
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.embedded.TestSolrProperties.testProperties(TestSolrProperties.java:220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)




Build Log (for compile errors):
[...truncated 23173 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


[ 
https://issues.apache.org/jira/browse/SOLR-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102723#comment-13102723
 ] 

Jan Høydahl commented on SOLR-1979:
---

Any changes you'd like before committing this? Lance, what config param changes 
did you have in mind?

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


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

Jan Høydahl updated SOLR-1979:
--

  Description: 
Language identification from document fields, and mapping of field names to 
language-specific fields based on detected language.

Wrap the Tika LanguageIdentifier in an UpdateProcessor.

See user documentation at http://wiki.apache.org/solr/LanguageDetection

  was:
Language identification from document fields, and mapping of field names to 
language-specific fields based on detected language.

Wrap the Tika LanguageIdentifier in an UpdateProcessor.

Fix Version/s: 4.0

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5, 4.0

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.
 See user documentation at http://wiki.apache.org/solr/LanguageDetection

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1979) Create LanguageIdentifierUpdateProcessor


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

Jan Høydahl updated SOLR-1979:
--

Component/s: contrib - LangId

 Create LanguageIdentifierUpdateProcessor
 

 Key: SOLR-1979
 URL: https://issues.apache.org/jira/browse/SOLR-1979
 Project: Solr
  Issue Type: New Feature
  Components: contrib - LangId, update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Priority: Minor
  Labels: UpdateProcessor
 Fix For: 3.5, 4.0

 Attachments: SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, SOLR-1979.patch, 
 SOLR-1979.patch, SOLR-1979.patch


 Language identification from document fields, and mapping of field names to 
 language-specific fields based on detected language.
 Wrap the Tika LanguageIdentifier in an UpdateProcessor.
 See user documentation at http://wiki.apache.org/solr/LanguageDetection

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #238: POMs out of sync

2011-09-12 Thread Steven A Rowe

I can't reproduce this failure locally.

From 
https://builds.apache.org/job/Lucene-Solr-Maven-trunk/238/testReport/junit/org.apache.solr.client.solrj.embedded/TestSolrProperties/testProperties/:

=
java.lang.AssertionError: 
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.embedded.TestSolrProperties.testProperties(TestSolrProperties.java:220)
=

From TestSolrProperties.java:

=
215: FileInputStream fis = new FileInputStream(new File(solrXml.getParent(), 
solr-persist.xml));
216: try {
217:   Document document = builder.parse(fis);
218:   assertTrue(exists(/solr/cores[@defaultCoreName='core0'], document));
219:   assertTrue(exists(/solr/cores[@host='127.0.0.1'], document));
220:   assertTrue(exists(/solr/cores[@hostPort='8983'], document));
221:   assertTrue(exists(/solr/cores[@zkClientTimeout='8000'], document));
222:   assertTrue(exists(/solr/cores[@hostContext='solr'], document));
=

Unfortunately, tearDown() deletes solr-persist.xml, so the condition that 
caused the failure disappears after the test is run.

I've committed some debug printing on failure to the above section of code, so 
if it happens again we'll be able to see why.

Steve

 -Original Message-
 From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
 Sent: Monday, September 12, 2011 11:15 AM
 To: dev@lucene.apache.org
 Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #238: POMs out of sync
 
 Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/238/
 
 1 tests failed.
 REGRESSION:
 org.apache.solr.client.solrj.embedded.TestSolrProperties.testProperties
 
 Error Message:
 
 
 Stack Trace:
 java.lang.AssertionError:
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.assertTrue(Assert.java:43)
   at org.junit.Assert.assertTrue(Assert.java:54)
   at
 org.apache.solr.client.solrj.embedded.TestSolrProperties.testProperties(T
 estSolrProperties.java:220)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
 :57)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
 mpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMeth
 od.java:44)
   at
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallabl
 e.java:15)
   at
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod
 .java:41)
   at
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.
 java:20)
   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
   at
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
 :28)
   at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:3
 1)
   at
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.
 java:76)
   at
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner
 .java:148)
   at
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner
 .java:50)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java
 :28)
   at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:3
 1)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java
 :35)
   at
 org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Prov
 ider.java:146)
   at
 org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.jav
 a:97)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
 :57)
   at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
 mpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at
 org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(
 ProviderFactory.java:103)
   at $Proxy0.invoke(Unknown Source)
   at
 org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireS
 tarter.java:145)
   at
 org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(Suref
 ireStarter.java:87)
   at
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)

Re: svn commit: r1169816 - /lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java

2011-09-12 Thread Robert Muir

expunage? :)

On Mon, Sep 12, 2011 at 12:16 PM,  mikemcc...@apache.org wrote:
 Author: mikemccand
 Date: Mon Sep 12 16:16:18 2011
 New Revision: 1169816

 URL: http://svn.apache.org/viewvc?rev=1169816view=rev
 Log:
 clarify that IW.expungeDeletes relies on MP to determine merges

 Modified:
    lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java

 Modified: 
 lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java?rev=1169816r1=1169815r2=1169816view=diff
 ==
 --- lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java 
 (original)
 +++ lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java 
 Mon Sep 12 16:16:18 2011
 @@ -1901,7 +1901,14 @@ public class IndexWriter implements Clos
   }


 -  /** Expunges all deletes from the index.  When an index
 +  /** Requests an expungeDeletes operation, by invoking
 +   *  {@link MergePolicy#findMergesToExpungeDeletes}.
 +   *  The MergePolicy determines what merges should be done.
 +   *  For example, the default {@link TieredMergePolicy}
 +   *  will only expunage deletes from a segment if the
 +   *  percentage of deleted docs is over 10%.
 +   *
 +   *  pWhen an index
    *  has many document deletions (or updates to existing
    *  documents), it's best to either call optimize or
    *  expungeDeletes to remove all unused data in the index






-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1169816 - /lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java

2011-09-12 Thread Michael McCandless

Duh, fixed.  Thanks!

Mike McCandless

http://blog.mikemccandless.com

On Mon, Sep 12, 2011 at 12:31 PM, Robert Muir rcm...@gmail.com wrote:
 expunage? :)

 On Mon, Sep 12, 2011 at 12:16 PM,  mikemcc...@apache.org wrote:
 Author: mikemccand
 Date: Mon Sep 12 16:16:18 2011
 New Revision: 1169816

 URL: http://svn.apache.org/viewvc?rev=1169816view=rev
 Log:
 clarify that IW.expungeDeletes relies on MP to determine merges

 Modified:
    lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java

 Modified: 
 lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java?rev=1169816r1=1169815r2=1169816view=diff
 ==
 --- 
 lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java 
 (original)
 +++ 
 lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/IndexWriter.java 
 Mon Sep 12 16:16:18 2011
 @@ -1901,7 +1901,14 @@ public class IndexWriter implements Clos
   }


 -  /** Expunges all deletes from the index.  When an index
 +  /** Requests an expungeDeletes operation, by invoking
 +   *  {@link MergePolicy#findMergesToExpungeDeletes}.
 +   *  The MergePolicy determines what merges should be done.
 +   *  For example, the default {@link TieredMergePolicy}
 +   *  will only expunage deletes from a segment if the
 +   *  percentage of deleted docs is over 10%.
 +   *
 +   *  pWhen an index
    *  has many document deletions (or updates to existing
    *  documents), it's best to either call optimize or
    *  expungeDeletes to remove all unused data in the index






 --
 lucidimagination.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Tika can not parse all of the persian pdf files

2011-09-12 Thread Robert Muir

Is it possible for you to create a new JIRA issue at
https://issues.apache.org/jira/browse/TIKA and upload the file
(checking the box for Grant license to ASF for inclusion in ASF
works) ?

Checking this box is really important: if there is a bug in
TIKA/PDFBox with your persian document, it would allow those projects
to add the PDF file to regression tests.

On Mon, Sep 12, 2011 at 3:47 AM, ahmad ajiloo ahmad.aji...@gmail.com wrote:
 yes, of course!
 please find the attachment.

 On Mon, Sep 12, 2011 at 9:42 AM, Robert Muir rcm...@gmail.com wrote:

 2011/9/12 ahmad ajiloo ahmad.aji...@gmail.com:
  Hello
  I used Tika (of course in Nutch) to parse some persian pdf files. some
  of
  the files clearly transformed to a plain text. but about some of them,
  output was corrupted. I used ICU4J v4 library and the text changed to
  right-to-left mode. but the mentioned problem didn't resolve. insofar as
  Tika can not understand any charachter of input persian pdf file!

 Maybe you can upload one of your PDF files to a Tika or PDFBox JIRA
 issue so they can investigate the problem?

 --
 lucidimagination.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Michael McCandless

On Mon, Sep 12, 2011 at 6:20 AM, Martijn v Groningen
martijn.v.gronin...@gmail.com wrote:
 +1 All tests passed on my machine.
 The Lucene release notes do contain some old highlights like join
 module.

By release notes, you mean the draft 3.4 release announcement, ie this
wiki page:

http://wiki.apache.org/lucene-java/ReleaseNote34

?

 I assume this will be removed, right?

This (lucene/contrib/join) is actually new in 3.4.0, so we should
highlight it now.

Mike

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.

StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate 
the RequestWriter API so that it can be used to send binary update payloads.
---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
 Fix For: 3.4


The aim of this patch is to use the RequestWriter API with 
StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.


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

Patrick Sauts updated SOLR-2755:


Attachment: patch-StreamingUpdateSolrServer.txt

 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.
 ---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
  Labels: patch
 Fix For: 3.4

 Attachments: patch-StreamingUpdateSolrServer.txt


 The aim of this patch is to use the RequestWriter API with 
 StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1565) StreamingUpdateSolrServer should support RequestWriter API


[ 
https://issues.apache.org/jira/browse/SOLR-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102828#comment-13102828
 ] 

Patrick Sauts commented on SOLR-1565:
-

proposal bugfix : https://issues.apache.org/jira/browse/SOLR-2755

 StreamingUpdateSolrServer should support RequestWriter API
 --

 Key: SOLR-1565
 URL: https://issues.apache.org/jira/browse/SOLR-1565
 Project: Solr
  Issue Type: Improvement
  Components: clients - java, update
Affects Versions: 1.4
Reporter: Shalin Shekhar Mangar
 Fix For: 3.4, 4.0

 Attachments: BinaryStreamingUpdateSolrServer.java


 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.


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

Patrick Sauts updated SOLR-2755:


Attachment: (was: patch-StreamingUpdateSolrServer.txt)

 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.
 ---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
  Labels: patch
 Fix For: 3.4

 Attachments: patch-StreamingUpdateSolrServer.txt


 The aim of this patch is to use the RequestWriter API with 
 StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.


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

Patrick Sauts updated SOLR-2755:


Attachment: patch-StreamingUpdateSolrServer.txt

 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.
 ---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
  Labels: patch
 Fix For: 3.4

 Attachments: patch-StreamingUpdateSolrServer.txt


 The aim of this patch is to use the RequestWriter API with 
 StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1565) StreamingUpdateSolrServer should support RequestWriter API


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

Patrick Sauts updated SOLR-1565:


Attachment: (was: BinaryStreamingUpdateSolrServer.java)

 StreamingUpdateSolrServer should support RequestWriter API
 --

 Key: SOLR-1565
 URL: https://issues.apache.org/jira/browse/SOLR-1565
 Project: Solr
  Issue Type: Improvement
  Components: clients - java, update
Affects Versions: 1.4
Reporter: Shalin Shekhar Mangar
 Fix For: 3.4, 4.0


 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-1565) StreamingUpdateSolrServer should support RequestWriter API


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

Patrick Sauts updated SOLR-1565:


Comment: was deleted

(was: I’ve made a alpha version of StreamingUpdateSolrServer dedicated to 
Binary update using javabin, It works fine for me.
I have attached it to this issue BinaryStreamingUpdateSolrServer.java

It is not a fix of the issue SOLR-1565, it is a new class.
But I think It can maybe be useful to fix the bug.

If somebody tests it thank you to send feedback.

Patrick Sauts)

 StreamingUpdateSolrServer should support RequestWriter API
 --

 Key: SOLR-1565
 URL: https://issues.apache.org/jira/browse/SOLR-1565
 Project: Solr
  Issue Type: Improvement
  Components: clients - java, update
Affects Versions: 1.4
Reporter: Shalin Shekhar Mangar
 Fix For: 3.4, 4.0


 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.


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

Patrick Sauts updated SOLR-2755:


Attachment: (was: patch-StreamingUpdateSolrServer.txt)

 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.
 ---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
  Labels: patch
 Fix For: 3.4

 Attachments: patch-StreamingUpdateSolrServer.txt


 The aim of this patch is to use the RequestWriter API with 
 StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.


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

Patrick Sauts updated SOLR-2755:


Attachment: patch-StreamingUpdateSolrServer.txt

 StreamingUpdateSolrServer is hard-coded to write XML data. It should 
 integrate the RequestWriter API so that it can be used to send binary update 
 payloads.
 ---

 Key: SOLR-2755
 URL: https://issues.apache.org/jira/browse/SOLR-2755
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: Patrick Sauts
  Labels: patch
 Fix For: 3.4

 Attachments: patch-StreamingUpdateSolrServer.txt


 The aim of this patch is to use the RequestWriter API with 
 StreamingUpdateSolrServer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2630) XsltUpdateRequestHandler


[ 
https://issues.apache.org/jira/browse/SOLR-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102849#comment-13102849
 ] 

David Smiley commented on SOLR-2630:


Just a side comment...
  I've been posting arbitrary XSLT and transforming it before this patch using 
the DIH ContentStreamDataSource: 
http://wiki.apache.org/solr/DataImportHandler#ContentStreamDataSource 

 XsltUpdateRequestHandler
 

 Key: SOLR-2630
 URL: https://issues.apache.org/jira/browse/SOLR-2630
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 3.3, 4.0
Reporter: Upayavira
Assignee: Uwe Schindler
Priority: Minor
 Fix For: 3.4, 4.0

 Attachments: xslt-update-handler.patch, xslt-update-handler.patch


 An update request handler that can accept a tr param, allowing the indexing 
 of any XML content that is passed to solr, so long as there is an XSLT 
 stylesheet in solr/conf/xslt that can transform it to the adddoc//add 
 format.
 Could be used, for example, to allow Solr to ingest docbook directly, without 
 any preprocessing.
  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3428) trunk tests hang/deadlock TestIndexWriterWithThreads

2011-09-12 Thread Simon Willnauer (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102938#comment-13102938
 ] 

Simon Willnauer commented on LUCENE-3428:
-

I committed the patch. I will keep this open for a while...

 trunk tests hang/deadlock TestIndexWriterWithThreads
 

 Key: LUCENE-3428
 URL: https://issues.apache.org/jira/browse/LUCENE-3428
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Simon Willnauer
 Attachments: LUCENE-3428.patch


 trunk tests have been hanging often lately in hudson, this time i was careful 
 to kill and get a good stacktrace:

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102941#comment-13102941
 ] 

David Smiley commented on SOLR-2756:


I'm willing to add a patch once we get consensus.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3429) improve build system when tests hang

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

Dawid Weiss updated LUCENE-3429:

Attachment: LUCENE-3429.patch

Suggested patch introducing method-level timeouts and seed/details reporting.

improve build system when tests hang

Key: LUCENE-3429
URL: https://issues.apache.org/jira/browse/LUCENE-3429
Project: Lucene - Java
Issue Type: Test
Reporter: Robert Muir
Fix For: 3.5, 4.0

Attachments: LUCENE-3429.patch, LUCENE-3429.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102990#comment-13102990
 ] 

Martijn van Groningen commented on SOLR-2756:
-

+1 The lucene-core dependency should be removed. Solr is Java 1.6, so 
geronimo-stax-api and wstx-asl can also be removed.
In the trunk there is SolrCloud code in the commons.cloud package. I'm not sure 
why this is put in the solrj source tree.
In the 3x the zookeeper can be removed.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Martijn v Groningen

I was confused about this. I thought the join contrib was released
with 3.3 release, but it wasn't. So we should highlight it now!

On 12 September 2011 18:41, Michael McCandless
luc...@mikemccandless.com wrote:
 On Mon, Sep 12, 2011 at 6:20 AM, Martijn v Groningen
 martijn.v.gronin...@gmail.com wrote:
 +1 All tests passed on my machine.
 The Lucene release notes do contain some old highlights like join
 module.

 By release notes, you mean the draft 3.4 release announcement, ie this
 wiki page:

    http://wiki.apache.org/lucene-java/ReleaseNote34

 ?

 I assume this will be removed, right?

 This (lucene/contrib/join) is actually new in 3.4.0, so we should
 highlight it now.

 Mike

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org





-- 
Met vriendelijke groet,

Martijn van Groningen

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3360) Move FieldCache to IndexReader


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

Martijn van Groningen updated LUCENE-3360:
--

Attachment: LUCENE-3360.patch

Small update. During testing SOLR-2066 I noticed that unnecessary 
ReaderFinishedListener instances were created in SlowMultiReaderWrapper (I had 
a OOME). This is fixed now.  

 Move FieldCache to IndexReader
 --

 Key: LUCENE-3360
 URL: https://issues.apache.org/jira/browse/LUCENE-3360
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Martijn van Groningen
 Fix For: 3.5, 4.0

 Attachments: LUCENE-3360-3x.patch, LUCENE-3360.patch, 
 LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, 
 LUCENE-3360.patch


 Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so 
 that FieldCache insanity caused by the WeakHashMap no longer occurs.
 * Add a new method to IndexReader that by default throws an UOE:
 {code}public FieldCache getFieldCache(){code}
 * The SegmentReader implements this method and returns its own internal 
 FieldCache implementation. This implementation just uses a 
 HashMapEntryT,Object to store entries.
 * The SlowMultiReaderWrapper implements this method as well and basically 
 behaves the same as the current FieldCacheImpl.
 This issue won't solve the insanity that comes from inconsistent usage of a 
 single field (for example retrieve both int[] and DocTermIndex for the same 
 field). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core

2011-09-12 Thread Uwe Schindler (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102999#comment-13102999
 ] 

Uwe Schindler commented on SOLR-2756:
-

Only Solr trunk is Java 1.6. 3.x is still Java 5.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103004#comment-13103004
 ] 

Martijn van Groningen commented on SOLR-2756:
-

Oops.. in that case the 3x branch should then have the java5 profile

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103005#comment-13103005
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. lucene-core dependency should be removed

I don't think it can be.  When I tried, compilation fails:

{noformat}
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[19,29]
 package org.apache.lucene.util does not exist
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[353,38]
 cannot find symbol
symbol  : class PriorityQueue
location: class org.apache.solr.common.util.ConcurrentLRUCacheK,V
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[320,24]
 cannot find symbol
symbol  : method size()
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[320,58]
 cannot find symbol
symbol  : method size()
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[321,56]
 cannot find symbol
symbol  : method pop()
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[358,6]
 non-static variable super cannot be referenced from a static context
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[358,11]
 cannot find symbol
symbol  : method initialize(int)
location: class java.lang.Object
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[359,13]
 cannot find symbol
symbol  : method getHeapArray()
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[365,4]
 method does not override or implement a method from a supertype
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[373,10]
 non-static method size() cannot be referenced from a static context
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[374,8]
 cannot find symbol
symbol  : method add(java.lang.Object)
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[376,17]
 non-static method size() cannot be referenced from a static context
\svn\lucene\dev\branches\branch_3x\solr\solrj\src\java\org\apache\solr\common\util\ConcurrentLRUCache.java:[379,8]
 cannot find symbol
symbol  : method updateTop()
location: class org.apache.solr.common.util.ConcurrentLRUCache.PQueue
{noformat}

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103001#comment-13103001
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. Solr is Java 1.6, so geronimo-stax-api and wstx-asl can also be removed.

About geronimo-stax-api, that dependency could be placed in a Java 
1.5-activated profile.  

About wstx-asl, see SOLR-2054; I don't think this issue should decide that.


 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3429) improve build system when tests hang

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

Dawid Weiss updated LUCENE-3429:

Attachment: (was: LUCENE-3429.patch)

improve build system when tests hang

Key: LUCENE-3429
URL: https://issues.apache.org/jira/browse/LUCENE-3429
Project: Lucene - Java
Issue Type: Test
Reporter: Robert Muir
Fix For: 3.5, 4.0

Attachments: LUCENE-3429.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3429) improve build system when tests hang

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

Dawid Weiss updated LUCENE-3429:

Attachment: LUCENE-3429.patch

Updated slightly to avoid calling reportAdditionalFailureInfo before an actual
timeout is hit.

improve build system when tests hang

Key: LUCENE-3429
URL: https://issues.apache.org/jira/browse/LUCENE-3429
Project: Lucene - Java
Issue Type: Test
Reporter: Robert Muir
Fix For: 3.5, 4.0

Attachments: LUCENE-3429.patch, LUCENE-3429.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103020#comment-13103020
 ] 

David Smiley commented on SOLR-2756:


Ugh, well that sucks. Ideas:
# Perhaps the ConcurrentLRUCache can be omitted from the solrj jar? Off-hand, 
I'm not sure how to do this on the maven compile stage
# Put the dependency as optionaltrue/optional so that it is not 
transitively included.  This is the simplest solution, for sure. It still means 
that solrj includes classes that aren't actually used by solrj but requires 
Lucene.  But that's what ya get when you have a /util/ package so I suppose 
it's understandable.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103021#comment-13103021
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. zookeeper dependency should be removed. Is this used in Solr 4? Even if it 
is, it strikes me as an optional dependency.

+1 - the zookeeper jar is included and used in Solr 4 (for SolrCloud), but 
isn't included in branch_3x.


 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3429) improve build system when tests hang


[ 
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103026#comment-13103026
 ] 

Dawid Weiss commented on LUCENE-3429:
-

Errr... I get a repetitive vm crash after applying the above patch.
{noformat}
[junit] #
[junit] # A fatal error has been detected by the Java Runtime Environment:
[junit] #
[junit] #  EXCEPTION_ACCESS_VIOLATION (0xc005) at 
pc=0x6dae29a5, pid=4040, tid=5104
[junit] #
[junit] # JRE version: 6.0_26-b03
[junit] # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode 
windows-amd64 compressed oops)
[junit] # Problematic frame:
[junit] # V  [jvm.dll+0x2529a5]
[junit] #
[junit] # An error report file with more information is saved as:
[junit] # 
d:\work\apache.org\lucene.git\lucene\build\test\7\hs_err_pid4040.log
[junit] #
[junit] # If you would like to submit a bug report, please visit:
[junit] #   http://java.sun.com/webapps/bugreport/crash.jsp
[junit] #
[junit] Testsuite: org.Batch-With-Multiple-Tests
[junit] Testcase: org.Batch-With-Multiple-Tests:testFlushExceptions:
Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the 
report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited 
abnormally. Please note the time in the report does not reflect the time until 
the VM ex
it.
[junit] at java.lang.Thread.run(Thread.java:662)
[junit]
{noformat}
Is this something new or known? I'm on win7, 64-bit - can anybody check on 
other machines?

 improve build system when tests hang
 

 Key: LUCENE-3429
 URL: https://issues.apache.org/jira/browse/LUCENE-3429
 Project: Lucene - Java
  Issue Type: Test
Reporter: Robert Muir
 Fix For: 3.5, 4.0

 Attachments: LUCENE-3429.patch, LUCENE-3429.patch


 Currently, if tests hang in hudson it can go hung for days until we manually 
 kill it.
 The problem is that when a hang happens its probably serious, what we want to 
 do (I think), is:
 # time out the build.
 # ensure we have enough debugging information to hopefully fix any hang.
 So I think the ideal solution would be:
 # add a sysprop -D that LuceneTestCase respects, it could default to no 
 timeout at all (some value like zero).
 # when a timeout is set, LuceneTestCase spawns an additional timer thread for 
 the test class? method?
 # if the timeout is exceeded, LuceneTestCase dumps all thread/stack 
 information, random seed information to hopefully reproduce the hang, and 
 fails the test.
 # nightly builds would pass some reasonable -D for each test.
 separately, I think we should have an ant-level timeout for the whole 
 build, in case it goes completely crazy (e.g. jvm completely hangs or 
 something else), just as an additional safety.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103033#comment-13103033
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. 1. Perhaps the ConcurrentLRUCache can be omitted from the solrj jar? 
Off-hand, I'm not sure how to do this on the maven compile stage

Bad idea, unless you mean {{ConcurrentLRUCache}} should be moved to 
{{solr/core/}}; Solr's {{FastLRUCache}} uses {{ConcurrentLRUCache}}.

bq. 2. Put the dependency as optionaltrue/optional so that it is not 
transitively included. This is the simplest solution, for sure. It still means 
that solrj includes classes that aren't actually used by solrj but requires 
Lucene. But that's what ya get when you have a /util/ package so I suppose it's 
understandable.

Downstream users of {{ConcurrentLRUCache}} - a public class - would succeed at 
compilation, but fail at runtime.  Smells bad to me.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor

 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


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

Steven Rowe updated SOLR-2756:
--

Attachment: SOLR-2756-zookeeper-and-stax-api.patch

This patch removes the zookeeper dependency, and makes geronimo-stax-api a 
dependency only under Java 1.5.

Compiles for me under both Java 1.5 and 1.6.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor
 Attachments: SOLR-2756-zookeeper-and-stax-api.patch


 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 3.4.0, RC1

2011-09-12 Thread Yonik Seeley

On Fri, Sep 9, 2011 at 12:06 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 Please vote to release the RC1 artifacts at:

  https://people.apache.org/~mikemccand/staging_area/lucene-solr-3.4.0-RC1-rev1167142

 as Lucene 3.4.0 and Solr 3.4.0.

+1

-Yonik
http://www.lucene-eurocon.com - The Lucene/Solr User Conference

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103060#comment-13103060
 ] 

David Smiley commented on SOLR-2756:


Steve, in your patch, you forgot to put the woodstox jar into the jdk15 
profile, and ideally with runtime scope.  I am aware that Solr needs this on 
the server for some XSLT functions but that is not pertinent in the client.  
*also*, there appears to be dependency on stax:stax-api:jar:1.0.1 that is 
questionably if we already depend on geronimo's stax API -- which I assume is 
the same Stax API.

(thanks for doing the patch; I offered to do it)

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor
 Attachments: SOLR-2756-zookeeper-and-stax-api.patch


 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2066) Search Grouping: support distributed search

2011-09-12 Thread Jasper van Veghel (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103067#comment-13103067
 ] 

Jasper van Veghel commented on SOLR-2066:
-

Martijn, the problem seems to be with highlighting combined with empty result 
sets. When I modify the TestDistributedGrouping test as follows:

{code}// Test distributed grouping with empty indices
query(q, *:*, rows, 100, fl, id, + i1, group, true, 
group.field, i1, group.limit, 10, sort, i1 +  asc, id asc);
query(q, *:*, rows, 100, fl, id, + i1, group, true, 
group.field, i1, group.limit, 10, sort, i1 +  asc, id asc, 
hl,true,hl.fl,t1);{code}

I can reproduce the exact stacktrace. The exception doesn't occur with a 
populated index.

 Search Grouping: support distributed search
 ---

 Key: SOLR-2066
 URL: https://issues.apache.org/jira/browse/SOLR-2066
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley
 Fix For: 3.5, 4.0

 Attachments: SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, 
 SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, 
 SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch


 Support distributed field collapsing / search grouping.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103070#comment-13103070
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. I didn't mean to move ConcurrentLRUCache to solr/core, but I like that 
idea. How is it pertinent that FastLRUCache uses ConcurrentLRUCache?

Solr uses solrj for distributed search, and so depends on it (that and also 
because {{o.a.s.common.\*}} is housed under solrj).  AFAICT, {{FastLRUCache}} 
is the only consumer in Lucene/Solr-land of {{ConcurrentLRUCache}}.

Does that answer your question?

bq. SolrJ's core function is to be a client to Solr, remember. Lets not trigger 
dependencies not needed for it's core function.

Solrj has the additional core function of enabling distributed search.


 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor
 Attachments: SOLR-2756-zookeeper-and-stax-api.patch


 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103074#comment-13103074
 ] 

Steven Rowe commented on SOLR-2756:
---

bq. Steve, in your patch, you forgot to put the woodstox jar into the jdk15 
profile, and ideally with runtime scope.

I didn't forget.  See my [above comment|#comment-13103001] about SOLR-2054.

bq. *also*, there appears to be dependency on stax:stax-api:jar:1.0.1 that is 
questionably if we already depend on geronimo's stax API - which I assume is 
the same Stax API.

I agree - this transitive dependency should be excluded.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor
 Attachments: SOLR-2756-zookeeper-and-stax-api.patch


 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2752) leader-per-shard


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

Mark Miller updated SOLR-2752:
--

Attachment: SOLR-2752.patch

Another patch I suppose - rename existing tests to 
LeaderElectionIntegrationTest and a new LeaderElectionTest that just tests the 
LeaderElector class itself. Also a bit more javadoc.

 leader-per-shard
 

 Key: SOLR-2752
 URL: https://issues.apache.org/jira/browse/SOLR-2752
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Yonik Seeley
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2752.patch, SOLR-2752.patch, SOLR-2752.patch, 
 SOLR-2752.patch, SOLR-2752.patch


 We need to add metadata into zookeeper about who is the leader for each 
 shard, and have some kind of leader election.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2752) leader-per-shard


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

Mark Miller updated SOLR-2752:
--

Attachment: SOLR-2752.patch

Another patch I suppose - rename existing tests to 
LeaderElectionIntegrationTest and a new LeaderElectionTest that just tests the 
LeaderElector class itself. Also a bit more javadoc.

 leader-per-shard
 

 Key: SOLR-2752
 URL: https://issues.apache.org/jira/browse/SOLR-2752
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Yonik Seeley
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2752.patch, SOLR-2752.patch, SOLR-2752.patch, 
 SOLR-2752.patch, SOLR-2752.patch


 We need to add metadata into zookeeper about who is the leader for each 
 shard, and have some kind of leader election.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2752) leader-per-shard


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

Mark Miller updated SOLR-2752:
--

Comment: was deleted

(was: Another patch I suppose - rename existing tests to 
LeaderElectionIntegrationTest and a new LeaderElectionTest that just tests the 
LeaderElector class itself. Also a bit more javadoc.)

 leader-per-shard
 

 Key: SOLR-2752
 URL: https://issues.apache.org/jira/browse/SOLR-2752
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Yonik Seeley
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2752.patch, SOLR-2752.patch, SOLR-2752.patch, 
 SOLR-2752.patch, SOLR-2752.patch


 We need to add metadata into zookeeper about who is the leader for each 
 shard, and have some kind of leader election.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2752) leader-per-shard


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

Mark Miller updated SOLR-2752:
--

Attachment: (was: SOLR-2752.patch)

 leader-per-shard
 

 Key: SOLR-2752
 URL: https://issues.apache.org/jira/browse/SOLR-2752
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Yonik Seeley
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-2752.patch, SOLR-2752.patch, SOLR-2752.patch, 
 SOLR-2752.patch, SOLR-2752.patch


 We need to add metadata into zookeeper about who is the leader for each 
 shard, and have some kind of leader election.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2756) SolrJ maven dependencies are faulty; needless dependency on lucene-core


[ 
https://issues.apache.org/jira/browse/SOLR-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103103#comment-13103103
 ] 

Steven Rowe commented on SOLR-2756:
---

On [#lucene-dev 
IRC|http://colabti.org/irclogger/irclogger_log/lucene-dev?date=2011-09-12#l119],
 David pointed out that Solr's use of Solrj for distributed search was 
irrelevant to the issue of whether Solrj's dependency on lucene-core should be 
made optional; I agreed.

However, because {{ConcurrentLRUCache}} is the only class in Solrj that 
requires the lucene-core dependency, and solr-core's {{FastLRUCache}} is the 
only Lucene/Solr use of {{ConcurrentLRUCache}}, I think {{ConcurrentLRUCache}} 
should be moved from Solrj to solr-core.

 SolrJ maven dependencies are faulty; needless dependency on lucene-core
 ---

 Key: SOLR-2756
 URL: https://issues.apache.org/jira/browse/SOLR-2756
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor
 Attachments: SOLR-2756-zookeeper-and-stax-api.patch


 I included a SolrJ 3.3 dependency into a new project and I noticed needless 
 dependencies transitive show up.
 Here is a subset of the output from mvn dependency:tree:
 {noformat}
 [INFO] +- org.apache.solr:solr-solrj:jar:3.3.0:compile
 [INFO] |  +- org.apache.lucene:lucene-core:jar:3.3.0:compile
 [INFO] |  +- commons-httpclient:commons-httpclient:jar:3.1:compile
 [INFO] |  |  \- commons-codec:commons-codec:jar:1.2:compile
 [INFO] |  +- 
 org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
 [INFO] |  +- org.apache.zookeeper:zookeeper:jar:3.3.1:compile
 [INFO] |  |  +- log4j:log4j:jar:1.2.15:compile
 [INFO] |  |  |  \- javax.mail:mail:jar:1.4:compile
 [INFO] |  |  | \- javax.activation:activation:jar:1.1:compile
 [INFO] |  |  \- jline:jline:jar:0.9.94:compile
 [INFO] |  \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:compile
 [INFO] | \- stax:stax-api:jar:1.0.1:compile
 {noformat}
 Clearly there is an inconsistency with solr/dist/solrj-lib and this list.
 * lucene-core dependency should be removed
 * AFAIK, geronimo-stax-api and wstx-asl are only needed for Java 1.5.  Right? 
  These can be put in a maven profile activated by jdk1.5.
 * zookeeper dependency should be removed. Is this used in Solr 4?  Even if it 
 is, it strikes me as an optional dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2066) Search Grouping: support distributed search


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

Martijn van Groningen updated SOLR-2066:


Attachment: SOLR-2066.patch

Thanks Jasper! I added your test case and I also added a bug fix for it. So it 
shouldn't occur any more!

 Search Grouping: support distributed search
 ---

 Key: SOLR-2066
 URL: https://issues.apache.org/jira/browse/SOLR-2066
 Project: Solr
  Issue Type: Sub-task
Reporter: Yonik Seeley
 Fix For: 3.5, 4.0

 Attachments: SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, 
 SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, 
 SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, 
 SOLR-2066.patch


 Support distributed field collapsing / search grouping.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3429) improve build system when tests hang

2011-09-12 Thread Robert Muir (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103221#comment-13103221
]

Robert Muir commented on LUCENE-3429:
-

Does this jre crash occur when you interrupt() a thread?

improve build system when tests hang

Key: LUCENE-3429
URL: https://issues.apache.org/jira/browse/LUCENE-3429
Project: Lucene - Java
Issue Type: Test
Reporter: Robert Muir
Fix For: 3.5, 4.0

Attachments: LUCENE-3429.patch, LUCENE-3429.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2757) Switch min(a,b) function to min(a,b,...)

2011-09-12 Thread Bill Bell (JIRA)


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

Bill Bell updated SOLR-2757:


Description: 
Would like the ability to use min(1,5,10,11) to return 1. To do that today it 
is parenthesis nightmare:
min(min(min(1,5),10),11)

Should extend max() as well.

  was:
Would like the ability to use min(1,5,10,11) to return 1. To o that today it is 
parenthesis nightmare:
min(min(min(1,5),10),11)

Should extend max() as well.


 Switch min(a,b) function to min(a,b,...)
 

 Key: SOLR-2757
 URL: https://issues.apache.org/jira/browse/SOLR-2757
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.4
Reporter: Bill Bell
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 Would like the ability to use min(1,5,10,11) to return 1. To do that today it 
 is parenthesis nightmare:
 min(min(min(1,5),10),11)
 Should extend max() as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2757) Switch min(a,b) function to min(a,b,...)

2011-09-12 Thread Bill Bell (JIRA)

Switch min(a,b) function to min(a,b,...)


 Key: SOLR-2757
 URL: https://issues.apache.org/jira/browse/SOLR-2757
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.4
Reporter: Bill Bell
Priority: Minor


Would like the ability to use min(1,5,10,11) to return 1. To o that today it is 
parenthesis nightmare:
min(min(min(1,5),10),11)

Should extend max() as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2749) use BoundaryScanner in Solr FVH

2011-09-12 Thread Koji Sekiguchi (JIRA)


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

Koji Sekiguchi updated SOLR-2749:
-

Attachment: SOLR-2749.patch

New patch. Almost done except test cases.

 use BoundaryScanner in Solr FVH
 ---

 Key: SOLR-2749
 URL: https://issues.apache.org/jira/browse/SOLR-2749
 Project: Solr
  Issue Type: New Feature
  Components: highlighter
Reporter: Koji Sekiguchi
Priority: Minor
 Attachments: SOLR-2749.patch, SOLR-2749.patch


 After LUCENE-1824 committed, Solr FragmentsBuilder can snip off at the 
 natural boundary by nature. But to bring out the full feature, Solr should 
 take care of arbitrary BoundaryScanner in solrconfig.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2758) ConcurrentLRUCache should move from common/util to solr/util

ConcurrentLRUCache should move from common/util to solr/util


 Key: SOLR-2758
 URL: https://issues.apache.org/jira/browse/SOLR-2758
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 3.3
Reporter: David Smiley
Priority: Minor


There is exactly one small dependency that the SolrJ jar has to lucene-core and 
that is indirectly via ConcurrentLRUCache which is in common/util.  SolrJ 
doesn't even use this cache but it's there any way.  Attached is a patch for 
the move. It also removes the lucene-core dependency that the SolrJ maven 
pom.xml has on lucene-core.

Steve Rowe agrees:
https://issues.apache.org/jira/browse/SOLR-2756?focusedCommentId=13103103page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13103103

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2758) ConcurrentLRUCache should move from common/util to solr/util