date:20120307


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

Dawid Weiss commented on SOLR-3206:
---

It's a problem in the test -- it attempts to generate a log name and overflows 
on the last digit from '9' to ':'.

 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)
 -

 Key: SOLR-3206
 URL: https://issues.apache.org/jira/browse/SOLR-3206
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
  Labels: seed-doesnt-reproduce
 Fix For: 4.0

 Attachments: error.log, output.log


 Failure on the build server. Looks like a number parsing problem but I cannot 
 reproduce with the same seed.
 {noformat}
 build 06-Mar-2012 08:11:20[junit] Testcase: 
 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery):Caused an 
 ERROR
 build 06-Mar-2012 08:11:20[junit] org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] java.lang.RuntimeException: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:152)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:135)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:125)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:351)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.search.TestRecovery.testRecoveryMultipleLogs(TestRecovery.java:797)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:736)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:632)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:531)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:593)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:614)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:498)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:216)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:140)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException: Error Instantiating Update Handler, 
 solr.DirectUpdateHandler2 failed to instantiate 
 org.apache.solr.update.UpdateHandler
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:475)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:598)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.reflect.InvocationTargetException
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:418)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.NumberFormatException: For input string: 01:
 build 06-Mar-2012 08:11:20[junit] at

[jira] [Resolved] (SOLR-3206) testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)

2012-03-07 Thread Dawid Weiss (Resolved) (JIRA)


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

Dawid Weiss resolved SOLR-3206.
---

Resolution: Fixed

 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)
 -

 Key: SOLR-3206
 URL: https://issues.apache.org/jira/browse/SOLR-3206
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
  Labels: seed-doesnt-reproduce
 Fix For: 4.0

 Attachments: error.log, output.log


 Failure on the build server. Looks like a number parsing problem but I cannot 
 reproduce with the same seed.
 {noformat}
 build 06-Mar-2012 08:11:20[junit] Testcase: 
 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery):Caused an 
 ERROR
 build 06-Mar-2012 08:11:20[junit] org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] java.lang.RuntimeException: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:152)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:135)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:125)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:351)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.search.TestRecovery.testRecoveryMultipleLogs(TestRecovery.java:797)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:736)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:632)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:531)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:593)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:614)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:498)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:216)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:140)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException: Error Instantiating Update Handler, 
 solr.DirectUpdateHandler2 failed to instantiate 
 org.apache.solr.update.UpdateHandler
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:475)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:598)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.reflect.InvocationTargetException
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:418)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.NumberFormatException: For input string: 01:
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.Long.parseLong(Long.java:419)

[jira] [Assigned] (SOLR-3206) testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)

2012-03-07 Thread Dawid Weiss (Assigned) (JIRA)


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

Dawid Weiss reassigned SOLR-3206:
-

Assignee: Dawid Weiss

 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery)
 -

 Key: SOLR-3206
 URL: https://issues.apache.org/jira/browse/SOLR-3206
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
  Labels: seed-doesnt-reproduce
 Fix For: 4.0

 Attachments: error.log, output.log


 Failure on the build server. Looks like a number parsing problem but I cannot 
 reproduce with the same seed.
 {noformat}
 build 06-Mar-2012 08:11:20[junit] Testcase: 
 testRecoveryMultipleLogs(org.apache.solr.search.TestRecovery):Caused an 
 ERROR
 build 06-Mar-2012 08:11:20[junit] org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] java.lang.RuntimeException: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:152)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:135)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:125)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:351)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.search.TestRecovery.testRecoveryMultipleLogs(TestRecovery.java:797)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:736)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:632)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:531)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:593)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:614)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:498)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness$Initializer.initialize(TestHarness.java:216)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.util.TestHarness.init(TestHarness.java:140)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 org.apache.solr.common.SolrException: Error Instantiating Update Handler, 
 solr.DirectUpdateHandler2 failed to instantiate 
 org.apache.solr.update.UpdateHandler
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:425)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:475)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:598)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.reflect.InvocationTargetException
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 build 06-Mar-2012 08:11:20[junit] at 
 org.apache.solr.core.SolrCore.createInstance(SolrCore.java:418)
 build 06-Mar-2012 08:11:20[junit] Caused by: 
 java.lang.NumberFormatException: For input string: 01:
 build 06-Mar-2012 08:11:20[junit] at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 build 06-Mar-2012 08:11:20[junit] at

[JENKINS] Lucene-trunk - Build # 1853 - Failure

2012-03-07 Thread Stefan Matheis (steffkes) (Commented) (JIRA)

Build: https://builds.apache.org/job/Lucene-trunk/1853/

No tests ran.

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



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

[jira] [Commented] (SOLR-3205) Better error reporting from Analysis UI


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

Stefan Matheis (steffkes) commented on SOLR-3205:
-

Yes, pretty good - i'll update the error handling and see how it goes :

 Better error reporting from Analysis UI
 ---

 Key: SOLR-3205
 URL: https://issues.apache.org/jira/browse/SOLR-3205
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Ryan McKinley
 Fix For: 4.0


 The new analysis UI does not behave well with invalid input.  To reproduce, 
 from /#/singlecore/analysis
  * Select a number field (int) 
  * put in invalid text (hello)
  * click Analyse Values
 The UI will have a red banner, but not say anything useful.  The log file 
 will say:
 {code}
 SEVERE: org.apache.solr.common.SolrException: Invalid Number: hello
   at 
 org.apache.solr.analysis.TrieTokenizer.reset(TrieTokenizerFactory.java:113)
   at 
 org.apache.solr.analysis.TrieTokenizer.init(TrieTokenizerFactory.java:76)
 {code}
 Hopefully we can get the UI to say Invalid Number: hello

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

The arguments that this is more than a maven issue are bogus.
Do you take me for a fool?

The same arguments could be had for even *released* dependencies like 
httpclient-3.0 that we use. What if a user wants to use 4.0?

To ant, whether its released or unreleased, its just a jar in a /lib and in the 
users classpath.
But thats not the real issue here: These people are angry about maven 
repositories.

So quit screwing around with crazy ideas about duplicating whole codebases and 
fix the real problem:

open a bug report at Maven with the Description:

*Allow maven project A to depend upon project B without B being in maven at all*

Thats the bug, it stops the replication of the virus, and i don't see any 
reason why maven wouldnt want to fix it? If they object, then it only proves my 
point that its really the GPLv3 of build tools.




 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Greg Stein (Commented) (JIRA)

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

Greg Stein commented on SOLR-3204:
--

Maven is a red herring.

The short answer is that the Lucene PMC is *releasing* artifacts (to the maven
repository) in the org.apache.commons namespace.

It doesn't matter how the release is done. You're doing it. You have released
Commons code to the public. Period. Stop pointing fingers at tools. The Lucene
PMC has released code in another project's namespace, which is *incompatible*
with the direction that project wants to take the namespace. The Lucene PMC has
no right to usurp the direction of other projects here at the ASF.

If you cannot get the tool to avoid releasing/interfering with other projects'
code, then stop using the tool. Seriously.

The Lucene PMC's releases should stop interfering with other projects'
namespaces. Find a way to fix it. Stop blaming tools. Start fixing.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

The solr-commons-csv artifact reused the code from the Apache Commons CSV
project but the package wasn't changed to something else than
org.apache.commons.csv in the process. This creates a compatibility issue as
the Apache Commons team works toward an official release of Commons CSV. It
prevents Commons CSV from using its own org.apache.commons.csv package, or
forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] Lucene-trunk - Build # 1851 - Failure

2012-03-07 Thread Robert Muir

Nice solution, thanks Uwe!

On Wed, Mar 7, 2012 at 2:43 AM, Uwe Schindler u...@thetaphi.de wrote:
 I opened https://issues.apache.org/jira/browse/INFRA-4521 for that.

 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de


 -Original Message-
 From: Uwe Schindler [mailto:u...@thetaphi.de]
 Sent: Wednesday, March 07, 2012 8:20 AM
 To: dev@lucene.apache.org
 Subject: RE: [JENKINS] Lucene-trunk - Build # 1851 - Failure

 Problem solved. The Jenkins slave is now using SVN 1.6.17. 1.7 port was
 uninstalled to prevent command-path clashes (/etc/alternatives or whatever).

 I will ask now infra and builds about their plans to upgrade the Jenkins 
 system
 to SVN 1.7, until that time we are fine with the old version.

 Uwe

 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de


  -Original Message-
  From: Uwe Schindler [mailto:u...@thetaphi.de]
  Sent: Wednesday, March 07, 2012 8:16 AM
  To: dev@lucene.apache.org
  Subject: RE: [JENKINS] Lucene-trunk - Build # 1851 - Failure
 
  Hi Robert,
 
  I was expecting this problem, but I have not seen any builds running that
 exec.
  In my opinion it’s a bad idea to use different versions of tools and
  in general calling the svnversion command from within a checkout or at
  least don’t enforce it to complete (what happens if you have no
  checkout at all? In that case Lucene also builds?). This is a problem
  here because Jenkins does not use the system SVN to checkout but the
  own Java-based bundled one. Means, the checkouts are only useable by
  Jenkins itself. Using svnversion from the code inside our build script
  conflicts and the svn export does not work (because revno is unknown).
 
  For now I will downgrade SVN to 1.6 on our box (build is currently running:
  make deinstall on subversion port, make install on subversion16 port)
  I will ask builds@ao, what they think about upgrading Jenkins-SVN
  (maybe Tmatesoft does not have a new client available - that's what I
 expect?).
 
  Uwe
 
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
   -Original Message-
   From: Robert Muir [mailto:rcm...@gmail.com]
   Sent: Wednesday, March 07, 2012 5:21 AM
   To: dev@lucene.apache.org
   Subject: Re: [JENKINS] Lucene-trunk - Build # 1851 - Failure
  
   My approach didn't work: it seems jenkins has its own older svn
   client that is conflicting with the svn on the system itself 
   (/usr/local/bin).
  
   So despite upgrading all the checkouts, i see:
  
   Checking out a fresh workspace because Jenkins failed to detect the
   current workspace
   /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-
   trunk-java7/checkout
   ERROR: svn: The path
   '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trun
   k-
   java7/checkout'
   appears to be part of a Subversion 1.7 or greater working copy.
   Please upgrade your Subversion client to use this working copy.
   org.tmatesoft.svn.core.SVNException: svn: The path
   '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trun
   k-
   java7/checkout'
   appears to be part of a Subversion 1.7 or greater working copy.
   Please upgrade your Subversion client to use this working copy.
  
   So its nuked all my efforts to upgrade these checkouts.
  
   We must either upgrade this jenkins-svn to 1.7, or downgrade our
   system svn (e.g. install ports/devel/subversion16 instead).
  
   I'll wait and see what Uwe thinks...
  
   On Tue, Mar 6, 2012 at 10:46 PM, Robert Muir rcm...@gmail.com
 wrote:
The issue is that svn was upgraded to 1.7. I'm svn upgrade'ing all
 checkouts.
   
On Tue, Mar 6, 2012 at 10:30 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
   
: Build: https://builds.apache.org/job/Lucene-trunk/1851/
:
: No tests ran.
   
Looks like same problem as the 3x branch: exec of svnversion is
failing, which makes me suspicious that it isn't in the path.
   
   
-Hoss
   
-
--
-- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
additional commands, e-mail: dev-h...@lucene.apache.org
   
   
   
   
--
lucidimagination.com
  
  
  
   --
   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


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

Re: [JENKINS] Lucene-trunk - Build # 1853 - Failure

2012-03-07 Thread Simon Willnauer

I committed a fix for this. Was a javadoc problem.

simon

On Wed, Mar 7, 2012 at 12:03 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-trunk/1853/

 No tests ran.

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




 -
 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] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SOLR-3204:
--

HTTClient 4 can coexist with HTTPClient 3 in the same classpath, because they 
are not in the same package.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] (LUCENE-3855) TestStressNRT failures (reproducible)

2012-03-07 Thread Dawid Weiss (Created) (JIRA)

TestStressNRT failures (reproducible)
-

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 4.0


Build server logs. Reproduces on at least two machines.

{noformat}
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
-Dtestmethod=test 
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
-Dargs=-Dfile.encoding=UTF-8
[junit] NOTE: test params are: codec=Lucene3x, 
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
timezone=Etc/GMT+1
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
(64-bit)/cpus=2,threads=1,free=74960064,total=135987200
[junit] -  ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT):  Caused 
an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open files: 
{_ng.cfs=8}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
there are still open files: {_ng.cfs=8}
[junit] at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
[junit] at 
org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
[junit] at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
[junit] at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
[junit] at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: _ng.cfs
[junit] at 
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at 
org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
[junit] at 
org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
[junit] at 
org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
[junit] at 
org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
[junit] at 
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
[junit] at 
org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
[junit] at 
org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
[junit] at 
org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
[junit] at 
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
[junit] at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
[junit] at 
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
[junit] 
[junit] 
[junit] Test org.apache.lucene.index.TestStressNRT FAILED
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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

A bug report for good morning ;)

2012-03-07 Thread Dawid Weiss

I fixed that Solr bug that was causing frequent errors on my build
machine. I also noticed this on trunk -- happened once, but is
reproducible.

https://issues.apache.org/jira/browse/LUCENE-3855

Dawid

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

[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)


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

Robert Muir commented on LUCENE-3855:
-

This must be a timing issue/race of some sort?

Doesn't reproduce on my machine... does it need multiple iterations usually to 
fail?

 TestStressNRT failures (reproducible)
 -

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 4.0


 Build server logs. Reproduces on at least two machines.
 {noformat}
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
 -Dtestmethod=test 
 -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
 -Dargs=-Dfile.encoding=UTF-8
 [junit] NOTE: test params are: codec=Lucene3x, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
 timezone=Etc/GMT+1
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestStressNRT]
 [junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
 (64-bit)/cpus=2,threads=1,free=74960064,total=135987200
 [junit] -  ---
 [junit] Testcase: test(org.apache.lucene.index.TestStressNRT):Caused 
 an ERROR
 [junit] MockDirectoryWrapper: cannot close: there are still open files: 
 {_ng.cfs=8}
 [junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
 there are still open files: {_ng.cfs=8}
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
 [junit]   at 
 org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: 
 _ng.cfs
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
 [junit]   at 
 org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
 [junit]   at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] 
 [junit] 
 [junit] Test org.apache.lucene.index.TestStressNRT FAILED
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LUCENE-3825) Please push maven snapshots to repositories.apache.org again


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

Steven Rowe commented on LUCENE-3825:
-

bq. Perhaps the last step is to now modify README.maven to point to 
https://repository.apache.org/content/repositories/snapshots/ instead of 
Jenkins?

Done - see 
[r1296722|http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/README.maven?r1=1150940r2=1296722pathrev=1296722diff_format=h]
 and 
[r1296723|http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/dev-tools/maven/README.maven?r1=1150941r2=1296723pathrev=1296723diff_format=h].

bq. As an aside, do you know why SSL is mandatory to access nexus? [...] If you 
don't know the answer, who/how should I inquire further?

Sorry, I don't know the answer to either question.  I would start asking either 
on #asfinfra or infrastruct...@apache.org, and they should be able to point you 
to the right person.

 Please push maven snapshots to repositories.apache.org again
 

 Key: LUCENE-3825
 URL: https://issues.apache.org/jira/browse/LUCENE-3825
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Affects Versions: 4.0
Reporter: Benson Margulies
Assignee: Steven Rowe
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3825-add-scm-to-poms-trunk.patch


 Once upon a time, snapshots of the lucene trunk went into the snapshot repo 
 at repositories.apache.org. No longer. Instead, they just sit at:
 https://builds.apache.org//job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts/
 Unfortunately, Jenkins makes a rather mediocre maven repo. the 
 maven-wagon-plugin can't copy it and Nexus can't proxy it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3074) SimpleTextCodec needs SimpleText DocValues impl


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

Robert Muir commented on LUCENE-3074:
-

Thanks Simon!

 SimpleTextCodec needs SimpleText DocValues impl
 ---

 Key: LUCENE-3074
 URL: https://issues.apache.org/jira/browse/LUCENE-3074
 Project: Lucene - Java
  Issue Type: Task
  Components: core/index, core/search
Affects Versions: 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Priority: Blocker
 Fix For: 4.0

 Attachments: LUCENE-3074.patch, LUCENE-3074.patch


 currently SimpleTextCodec uses binary docValues we should move that to a 
 simple text impl.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3855) TestStressNRT failures (reproducible)


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

Dawid Weiss commented on LUCENE-3855:
-

Ok, it doesn't always happen, but it happens quite frequently (I re-run the 
test from scratch, didn't use repetitions). Interestingly, the problem seems to 
be different every time. I'll attach logs.

 TestStressNRT failures (reproducible)
 -

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 4.0


 Build server logs. Reproduces on at least two machines.
 {noformat}
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
 -Dtestmethod=test 
 -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
 -Dargs=-Dfile.encoding=UTF-8
 [junit] NOTE: test params are: codec=Lucene3x, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
 timezone=Etc/GMT+1
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestStressNRT]
 [junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
 (64-bit)/cpus=2,threads=1,free=74960064,total=135987200
 [junit] -  ---
 [junit] Testcase: test(org.apache.lucene.index.TestStressNRT):Caused 
 an ERROR
 [junit] MockDirectoryWrapper: cannot close: there are still open files: 
 {_ng.cfs=8}
 [junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
 there are still open files: {_ng.cfs=8}
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
 [junit]   at 
 org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: 
 _ng.cfs
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
 [junit]   at 
 org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
 [junit]   at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] 
 [junit] 
 [junit] Test org.apache.lucene.index.TestStressNRT FAILED
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SOLR-2459) Implement LogLevelSelection as a RequestHandler

2012-03-07 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-2459:
--

Ryan:

Can we close this JIRA? Or are there additional issues pending?

 Implement LogLevelSelection as a RequestHandler
 ---

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial
 Attachments: LogLevelHandler.patch, SOLR-2459-LogLevel.patch, 
 SOLR-2459-LogLevel.patch, sample-output.json, sample-output.xml


 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3855) TestStressNRT failures (reproducible)

2012-03-07 Thread Dawid Weiss (Updated) (JIRA)


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

Dawid Weiss updated LUCENE-3855:


Attachment: output4.log
output3.log
output2.log
output1.log

Four executions, four errors (same seed).

 TestStressNRT failures (reproducible)
 -

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 4.0

 Attachments: output1.log, output2.log, output3.log, output4.log


 Build server logs. Reproduces on at least two machines.
 {noformat}
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
 -Dtestmethod=test 
 -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
 -Dargs=-Dfile.encoding=UTF-8
 [junit] NOTE: test params are: codec=Lucene3x, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
 timezone=Etc/GMT+1
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestStressNRT]
 [junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
 (64-bit)/cpus=2,threads=1,free=74960064,total=135987200
 [junit] -  ---
 [junit] Testcase: test(org.apache.lucene.index.TestStressNRT):Caused 
 an ERROR
 [junit] MockDirectoryWrapper: cannot close: there are still open files: 
 {_ng.cfs=8}
 [junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
 there are still open files: {_ng.cfs=8}
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
 [junit]   at 
 org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: 
 _ng.cfs
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
 [junit]   at 
 org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
 [junit]   at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] 
 [junit] 
 [junit] Test org.apache.lucene.index.TestStressNRT FAILED
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LUCENE-3855) TestStressNRT failures (reproducible)

2012-03-07 Thread Grant Ingersoll (Issue Comment Edited) (JIRA)


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

Dawid Weiss commented on LUCENE-3855:
-

{noformat}
junit-sequential:
[junit] Testsuite: org.apache.lucene.index.TestStressNRT
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 10.377 sec
[junit] 
[junit] - Standard Error -
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: Lucene Merge Thread #133 ***
[junit] org.apache.lucene.index.MergePolicy$MergeException: 
java.lang.AssertionError
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:507)
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
[junit] Caused by: java.lang.AssertionError
[junit] at 
org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3028)
[junit] at 
org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3137)
[junit] at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3718)
[junit] at 
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
[junit] at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
-Dtestmethod=test 
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
-Dargs=-Dfile.encoding=UTF-8
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
-Dtestmethod=test 
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
-Dargs=-Dfile.encoding=UTF-8
[junit] NOTE: test params are: codec=Lucene3x, 
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
timezone=Etc/GMT+1
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
(64-bit)/cpus=2,threads=1,free=86308600,total=202244096
[junit] -  ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT):  Caused 
an ERROR
[junit] java.lang.AssertionError: Some threads threw uncaught exceptions!
[junit] java.lang.RuntimeException: java.lang.AssertionError: Some threads 
threw uncaught exceptions!
[junit] at 
org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:816)
[junit] at 
org.apache.lucene.util.LuceneTestCase.access$1100(LuceneTestCase.java:137)
[junit] at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:640)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
[junit] at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] Caused by: java.lang.AssertionError: Some threads threw uncaught 
exceptions!
[junit] at 
org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:844)
[junit] at 
org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:788)
[junit] 
[junit] 

junit-sequential:
[junit] Testsuite: org.apache.lucene.index.TestStressNRT
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 11.454 sec
[junit] 
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
-Dtestmethod=test 
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
-Dargs=-Dfile.encoding=UTF-8
[junit] NOTE: test params are: codec=Lucene3x, 
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
timezone=Etc/GMT+1
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
(64-bit)/cpus=2,threads=1,free=77427992,total=143851520
[junit] -  ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT):  Caused 
an ERROR
[junit]

[jira] [Updated] (LUCENE-3807) Cleanup suggester API

2012-03-07 Thread Simon Willnauer (Updated) (JIRA)


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

Simon Willnauer updated LUCENE-3807:


Attachment: LUCENE-3807.patch

here is a new patch removing the file based store / load methods and adding a 
fileName method to solrs factories to maintain compatibility. I will commit 
this soon.

 Cleanup suggester API
 -

 Key: LUCENE-3807
 URL: https://issues.apache.org/jira/browse/LUCENE-3807
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/other
Affects Versions: 3.6, 4.0
Reporter: Simon Willnauer
 Fix For: 4.0

 Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, 
 LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, 
 LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807_3x.patch


 Currently the suggester api and especially TermFreqIterator don't play that 
 nice with BytesRef and other paradigms we use in lucene, further the java 
 iterator pattern isn't that useful when it gets to work with TermsEnum, 
 BytesRef etc. We should try to clean up this api step by step moving over to 
 BytesRef including the Lookup class and its interface...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3807) Cleanup suggester API

2012-03-07 Thread Simon Willnauer (Commented) (JIRA)


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

Simon Willnauer commented on LUCENE-3807:
-

backported committed patches to 3.x in rev 1297946

 Cleanup suggester API
 -

 Key: LUCENE-3807
 URL: https://issues.apache.org/jira/browse/LUCENE-3807
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/other
Affects Versions: 3.6, 4.0
Reporter: Simon Willnauer
 Fix For: 4.0

 Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, 
 LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, 
 LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807_3x.patch


 Currently the suggester api and especially TermFreqIterator don't play that 
 nice with BytesRef and other paradigms we use in lucene, further the java 
 iterator pattern isn't that useful when it gets to work with TermsEnum, 
 BytesRef etc. We should try to clean up this api step by step moving over to 
 BytesRef including the Lookup class and its interface...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Assigned] (SOLR-3140) Make omitNorms default for all numeric field types

2012-03-07 Thread Assigned


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

Jan Høydahl reassigned SOLR-3140:
-

Assignee: Jan Høydahl

 Make omitNorms default for all numeric field types
 --

 Key: SOLR-3140
 URL: https://issues.apache.org/jira/browse/SOLR-3140
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Jan Høydahl
Assignee: Jan Høydahl
  Labels: omitNorms
 Fix For: 3.6, 4.0

 Attachments: SOLR-3140.patch, SOLR-3140.patch


 Today norms are enabled for all Solr field types by default, while in Lucene 
 norms are omitted for the numeric types.
 Propose to make the Solr defaults the same as in Lucene, so that if someone 
 occasionally wants index-side boost for a numeric field type they must say 
 omitNorms=false. This lets us simplify the example schema too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Grant Ingersoll (Commented) (JIRA)

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

Grant Ingersoll commented on SOLR-3204:
---

I guess I'm missing something. We aren't part of the Commons project. The
Commons code is Apache licensed. What prevents someone else from going and
doing the same thing outside of Apache? In fact, it happens all the time, even
at Apache. Commons CLI 2 is the biggest one, as I know of several projects
that release that b/c Commons itself never has. Here are also several who do
it for Lucene. The problem *is* Maven and it isn't going away.

Here are some examples:
#
http://search.maven.org/#artifactdetails%7Corg.hibernate.apache.lucene.solr%7Capache-solr-analyzer%7C1.2.0%7Cjar
#
http://search.maven.org/#artifactdetails%7Corg.apache.clerezza.ext%7Corg.apache.lucene%7C0.1-incubating%7Cbundle

Tomcat does the same thing to Commons (file upload, for example):
# http://search.maven.org/#search%7Cga%7C4%7Ccommons

I could keep going. Just do searches for popular Apache libraries in Maven and
you will see what I mean. Maven is not a red herring. It is the problem.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

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

Grant Ingersoll edited comment on SOLR-3204 at 3/7/12 1:18 PM:
---

I guess I'm missing something. We aren't part of the Commons project. The
Commons code is Apache licensed, we are using it as we see fit under the TC of
the ASL. What prevents someone else from going and doing the same thing
outside of Apache? In fact, it happens all the time, even at Apache. Commons
CLI 2 is the biggest one, as I know of several projects that release that b/c
Commons itself never has. Here are also several who do it for Lucene. The
problem *is* Maven and it isn't going away.

Tomcat does the same thing to Commons (file upload, for example):
# http://search.maven.org/#search%7Cga%7C4%7Ccommons

I could keep going. Just do searches for popular Apache libraries in Maven and
you will see what I mean. Maven is not a red herring. It is the problem.

was (Author: gsingers):
I guess I'm missing something. We aren't part of the Commons project. The
Commons code is Apache licensed. What prevents someone else from going and
doing the same thing outside of Apache? In fact, it happens all the time, even
at Apache. Commons CLI 2 is the biggest one, as I know of several projects
that release that b/c Commons itself never has. Here are also several who do
it for Lucene. The problem *is* Maven and it isn't going away.

Tomcat does the same thing to Commons (file upload, for example):
# http://search.maven.org/#search%7Cga%7C4%7Ccommons

I could keep going. Just do searches for popular Apache libraries in Maven and
you will see what I mean. Maven is not a red herring. It is the problem.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SOLR-3204:
--

That's not correct for Tomcat, the Commons components in Tomcat have a 
different namespace to avoid classpath conflicts.

Clerezza releases will have to be changed too.

Hibernate probably made a mistake in 2008, they haven't released a solr 
artifact since then, so I guess they fixed the issue.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Issue Comment Edited) (JIRA)


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

Emmanuel Bourg edited comment on SOLR-3204 at 3/7/12 1:41 PM:
--

That's not correct for Tomcat, the Commons components in Tomcat have a 
different namespace to avoid classpath conflicts.

Clerezza releases will have to be changed too.

Hibernate probably made a mistake in 2008, they haven't released a solr 
artifact since then, so I guess they fixed the issue.

EDIT: Indeed Hibernate fixed the dependency in Hibernate Search 3.3.0 Beta2, 
the dependency was introduced with the Beta 1

  was (Author: ebourg):
That's not correct for Tomcat, the Commons components in Tomcat have a 
different namespace to avoid classpath conflicts.

Clerezza releases will have to be changed too.

Hibernate probably made a mistake in 2008, they haven't released a solr 
artifact since then, so I guess they fixed the issue.
  
 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3192) NettySolrServer (supported by netty/protobuf) such as CommonsHttpSolrServer

2012-03-07 Thread Linbin Chen (Updated) (JIRA)


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

Linbin Chen updated SOLR-3192:
--

Assignee: (was: Yonik Seeley)

 NettySolrServer (supported by netty/protobuf) such as CommonsHttpSolrServer
 ---

 Key: SOLR-3192
 URL: https://issues.apache.org/jira/browse/SOLR-3192
 Project: Solr
  Issue Type: New Feature
Reporter: Linbin Chen
 Fix For: 4.0

 Attachments: solr.proto


 solr support netty tcp, netty/tcp can handle asynchronous,efficient,keepalive 
 ...
 it's used on solr cloud or solrj
 solr.proto maybe
 {code:java}
 package org.apache.solr.common.netty;
 option java_package = org.apache.solr.common.netty;
 option java_outer_classname = SolrProtocol;
 option optimize_for = SPEED;
 message SolrRequest {
   required int32 rid = 1;
   //for string, like http params
   required bytes params = 2;
   //(xml, json, solr_javabin) fix by params rt (request type)
   optional int32 streamsFormat = 3;
   repeated bytes streams = 4;
 }
 message SolrResponse {
   required int32 rid = 1;
   //response format (xml, json, solr_javabin, csv ...)
   optional int32 responseFormat = 2;
   optional bytes response = 3;
   optional int32 errorCode = 4;
   optional string errorStr = 5;
 }
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Grant Ingersoll (Commented) (JIRA)

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

Grant Ingersoll commented on SOLR-3204:
---

More that do it:
Geronimo (Apache) (Digester, Discovery)
JVNet-Hudson (commons-jelly)
com.kenai.nbpwr
ServiceMix (commons-csv)
Apache Directory does this weird thing where they package the Commons jars
inside of another jar. Not sure what that does, but the nested jar is Commons.
Not quite sure how the classloader would deal with that.
Mahout does it for Commons-CLI2 (b/c commons never seems to want to release it)

And that is just me searching for commons.

BTW, I don't actually think the problem is Maven. The problem is Java's
classloader is broken. The way to fix it is to use a classloader that scopes
dependencies properly. Otherwise, this is simply a known problem with Java and
the solution is that one has to be careful about what versions of things one
imports. It's exactly the same issue as when one has two dependencies that
each have dependencies on different versions of commons-lang or Lucene or
whats-it-called.jar.

In other words, -1 on us doing anything different than what we are already
doing. Except, for seeing if we can upgrade our version of Commons CSV to an
official release as a courtesy.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Grant Ingersoll (Issue Comment Edited) (JIRA)

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

Grant Ingersoll edited comment on SOLR-3204 at 3/7/12 1:45 PM:
---

And that is just me searching for commons.

In other words, I don't think this is worth us doing anything different than
what we are already doing. Except, for seeing if we can upgrade our version of
Commons CSV to an official release as a courtesy.

was (Author: gsingers):
More that do it:
Geronimo (Apache) (Digester, Discovery)
JVNet-Hudson (commons-jelly)
com.kenai.nbpwr
ServiceMix (commons-csv)
Apache Directory does this weird thing where they package the Commons jars
inside of another jar. Not sure what that does, but the nested jar is Commons.
Not quite sure how the classloader would deal with that.
Mahout does it for Commons-CLI2 (b/c commons never seems to want to release it)

And that is just me searching for commons.

In other words, -1 on us doing anything different than what we are already
doing. Except, for seeing if we can upgrade our version of Commons CSV to an
official release as a courtesy.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Grant Ingersoll (Commented) (JIRA)


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

Grant Ingersoll commented on SOLR-3204:
---

bq. That's not correct for Tomcat, the Commons components in Tomcat have a 
different namespace to avoid classpath conflicts.

Not in the ones I downloaded.



 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SOLR-3204:
--

Grant, get the latest ones:

http://www.jarvana.com/jarvana/inspect/org/apache/tomcat/tomcat-dbcp/7.0.23/tomcat-dbcp-7.0.23.jar


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Mike Sokolov (Commented) (JIRA)


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

Mike Sokolov commented on SOLR-3204:


' Short of removing Solr from Maven, is
there some way to publish Solr's WAR through Maven while keeping (some
of?) its dependencies private?

There is no issue for users of the WAR, I think, which will generally be 
external to a project, and handles all of these bundling issues internally.

The issue arises in projects that depend on the various solr jars that are 
bundled in its WAR.  Using Maven, it's as if you exploded the WAR, pulled all 
its jars into your project, and then added your own code too.  As an example, 
we've done this in a project where I work so we can run EmbeddedSolrServer in 
our tests. I have it on my TODO list to break this dependency though since it's 
overkill to include all of solr in our project for this convenience.  

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Mike Sokolov (Issue Comment Edited) (JIRA)


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

Mike Sokolov edited comment on SOLR-3204 at 3/7/12 2:27 PM:


There is no issue for users of the WAR, I think, which will generally be 
external to a project, and handles all of these bundling issues internally.

The issue arises in projects that depend on the various solr jars that are 
bundled in its WAR.  Using Maven, it's as if you exploded the WAR, pulled all 
its jars into your project, and then added your own code too.  As an example, 
we've done this in a project where I work so we can run EmbeddedSolrServer in 
our tests. I have it on my TODO list to break this dependency though since it's 
overkill to include all of solr in our project for this convenience.  

  was (Author: sokolov):
' Short of removing Solr from Maven, is
there some way to publish Solr's WAR through Maven while keeping (some
of?) its dependencies private?

There is no issue for users of the WAR, I think, which will generally be 
external to a project, and handles all of these bundling issues internally.

The issue arises in projects that depend on the various solr jars that are 
bundled in its WAR.  Using Maven, it's as if you exploded the WAR, pulled all 
its jars into your project, and then added your own code too.  As an example, 
we've done this in a project where I work so we can run EmbeddedSolrServer in 
our tests. I have it on my TODO list to break this dependency though since it's 
overkill to include all of solr in our project for this convenience.  
  
 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler commented on SOLR-3204:
-

As noted before, we cannot fix this for Jetty 6 by package-renaming using 
JarJar, as this would break almost everything in the jetty configuration (Jetty 
is JarJar unfriendly), but Jetty can be easily solved on our side by upgrading 
to Jetty 8 (also for Solr 3.6). The patch/branch is ready, just needs 
committing. We can then ship with unmodified Jetty 8, as the Unicode bugs 
should be fixed.

For the other projects I see no real problem in using jarjar (which is used in 
lots of projects): Lets simply investigate what foreign namespaces we use in 
our packages (e.g. we should also rename the Snowball classes, because we 
heavily forked them and they are still in org.tartarus namespace - as we forked 
that project, we should do it in the source code). For e.g. commons-csv we have 
no problem jarjaring our fork and re-release it. In the jarjar issue tracker is 
also a discussion about “hiding” renamed classes from GUIs by prefixing all 
renamed class names with $, so they are invisible for an autocomplete-using 
Eclipse developer, so nobody outside can use the jarjared classes outside 
Lucene/Solr.

About the remaining issues Robert mentioned: They are all solvable. JarJar 
renames also class names inside strings used for reflection, it can also 
rewrite Manifests and META-INF (we use e.g. for codecs, or Apache Xerces uses 
to plug in the parser impl). I just would like to give it a try, it cannot 
happen more than our testcases do not run. The example Robert has given with 
external references to icu4j is exactly what we want to prevent with JarJaring, 
so it doesn’t apply in my opinion. If we patch and modify icu4j and ship with a 
package-renamed version, code that uses reflection outside the Solr/Lucene JAR 
is completely unaffected. If the external project side-by-side with Lucene/Solr 
wants to use icu4j it can simply include the original in any version, solr with 
its patched version is completely unaffected and vice versa.

So I would strongly suggest to jarjar all dependencies that we modified locally 
(means all foreign jar-files with solr-prefix). How we do this is a different 
issue: We can only rename all classes in that jar-file and republish it (but 
then we have to change our import statements in our code – I would prefer 
this), or we jarjar the whole Solr distribution after the complete build.


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

How would this work for e.g. the carrot2 example? The carrot2 class names are 
referenced in user configuration files (solrconfig.xml):

For example:
{noformat}
lst name=engine
  !-- The name, only one can be named default --
  str name=namedefault/str
  str 
name=carrot.algorithmorg.carrot2.clustering.lingo.LingoClusteringAlgorithm/str
/lst
{noformat}

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

Also the UIMA integration has the same issue, configuration files contain their 
qualified class names, for example:

{noformat}
type allAnnotatorFeatures=trueorg.apache.uima.SentenceAnnotation/type
{noformat}

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SOLR-3204:
--

{quote}
How we do this is a different issue: We can only rename all classes in that 
jar-file and republish it (but then we have to change our import statements in 
our code – I would prefer this), or we jarjar the whole Solr distribution after 
the complete build.
{quote}

It's preferable to post process the Solr jar rather than renaming the packages 
imported in the source code. That's less intrusive and let you upgrade to the 
official fixed dependency more easily.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

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

Mark Miller commented on SOLR-3204:
---

As Mike and Yonik mentioned - most of us don't know much about maven. I still
wish it was a downstream issue. I still wish we would have voted on supporting
it. With all due respect to Steve and his great work around it. I really wish
it was not our problem - as I know many others do.

What was the issue with just using a released version of csv? This issue is so
long already, its hard to find it.

And -1 for continuing Maven support within the project for what its worth ;)
(Though I love your work and dedication to this Steve :) )

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

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

Robert Muir commented on SOLR-3204:
---

{quote}
What was the issue with just using a released version of csv? This issue is so
long already, its hard to find it.
{quote}

I think the major issue is that there is not yet a released version. I think we
would definitely prefer that.

Speaking from some experience: In my opinion CSV is deceptively complex and is
a perfect example of where we
would rather 'downstream' that knowledge to someone who focuses on it and gives
good performance.
Rolling our own is dangerous.

But there is not yet any official releases to use...

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Uwe Schindler (Issue Comment Edited) (JIRA)


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

Uwe Schindler commented on SOLR-3204:
-

{quote}
{quote}
How we do this is a different issue: We can only rename all classes in that 
jar-file and republish it (but then we have to change our import statements in 
our code – I would prefer this), or we jarjar the whole Solr distribution after 
the complete build.
{quote}

It's preferable to post process the Solr jar rather than renaming the packages 
imported in the source code. That's less intrusive and let you upgrade to the 
official fixed dependency more easily.
{quote}

That's our committers decision. The fact here is, that Solr or even Lucene is 
not just a WAR file, its consisting of lot's of unrelated JAR artifacts and all 
of them should live on its own, so a user can remove features he does not need. 
So I prefer to transform those changed artifacts separately to private 
namespace and simply change maybe 3 import statements (I can even use sed 
for that).

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler edited comment on SOLR-3204 at 3/7/12 3:30 PM:
-

{quote}
bq. How we do this is a different issue: We can only rename all classes in that 
jar-file and republish it (but then we have to change our import statements in 
our code – I would prefer this), or we jarjar the whole Solr distribution after 
the complete build.

It's preferable to post process the Solr jar rather than renaming the packages 
imported in the source code. That's less intrusive and let you upgrade to the 
official fixed dependency more easily.
{quote}

That's our committers decision. The fact here is, that Solr or even Lucene is 
not just a WAR file, its consisting of lot's of unrelated JAR artifacts and all 
of them should live on its own, so a user can remove features he does not need. 
So I prefer to transform those changed artifacts separately to private 
namespace and simply change maybe 3 import statements (I can even use sed 
for that).

  was (Author: thetaphi):
{quote}
{quote}
How we do this is a different issue: We can only rename all classes in that 
jar-file and republish it (but then we have to change our import statements in 
our code – I would prefer this), or we jarjar the whole Solr distribution after 
the complete build.
{quote}

It's preferable to post process the Solr jar rather than renaming the packages 
imported in the source code. That's less intrusive and let you upgrade to the 
official fixed dependency more easily.
{quote}

That's our committers decision. The fact here is, that Solr or even Lucene is 
not just a WAR file, its consisting of lot's of unrelated JAR artifacts and all 
of them should live on its own, so a user can remove features he does not need. 
So I prefer to transform those changed artifacts separately to private 
namespace and simply change maybe 3 import statements (I can even use sed 
for that).
  
 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3211) Allow parameter override in conjunction with spellcheck.maxCollationTries

2012-03-07 Thread James Dyer (Created) (JIRA)

Allow parameter override in conjunction with spellcheck.maxCollationTries
---

 Key: SOLR-3211
 URL: https://issues.apache.org/jira/browse/SOLR-3211
 Project: Solr
  Issue Type: Improvement
  Components: spellchecker
Affects Versions: 3.5
Reporter: James Dyer
Priority: Minor
 Fix For: 4.0


A couple users on the mailing list recently asked about being able to override 
the mm parameter when SpellCheckComponent issues queries to check for # hits 
for a collation candidate.  The issue is if the query had mm=0, pretty much 
everything will generate hits.  But for collation checking purposes, a low mm 
is almost never desirable.

It might be worthwhile to generalize this to let other parameters be overridden 
as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

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

Mark Miller commented on SOLR-3204:
---

bq. But there is not yet any official releases to use...

Ah, interesting. Perhaps we could get the favor of a release :)

It's 5 classes it looks like - and it's Apache licensed and there is no release
- can't we simply suck this into our code base with a readme and JIRA about
removing it and switching to a release when one occurs? Get the whole
dependency thing right out of Maven's claws.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Steven Rowe commented on SOLR-3204:
---

bq. So I prefer to transform those changed artifacts separately to private 
namespace and simply change maybe 3 import statements (I can even use sed 
for that).

+1

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Emmanuel Bourg (Commented) (JIRA)


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

Emmanuel Bourg commented on SOLR-3204:
--

That was the purpose of my patch Mark :)

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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: ideas for alphas/betas?

2012-03-07 Thread Tommaso Teofili

2012/3/7 Robert Muir rcm...@gmail.com

 On Tue, Mar 6, 2012 at 1:42 AM, Shai Erera ser...@gmail.com wrote:
  I agree.
 
  Maybe we should also tag issues as 4.0-alpha, 4.0-beta in JIRA? For
  4.0-alpha we'll tag all the issues that are expected to change the index
  format, and 4.0-beta all the issues that require API changes?
 

 I have no opinion on the actual JIRA tagging, but I think Hoss has a
 good point that it would be better if we looked at alphas/betas as
 real releases... ideally our first alpha release would be exactly
 the same as our real 4.0 release, but we are just being realistic and
 at the same time marking some caveats so that users know its a big
 scary change.

 So I'm not sure we should intentionally try to delay/bucket any issues
 to alpha or beta, I think we should try to make it great from the
 start... these 'guarantees' are just to help increase adoption and
 testing.


+1, as also Simon was saying let's go fixing the blockers and start working
on the alpha release process.

Tommaso



 --
 lucidimagination.com

 -
 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 #417: POMs out of sync

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

1 tests failed.
REGRESSION:  org.apache.lucene.search.TestNRTManager.testNRTManager

Error Message:
null

Stack Trace:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.lucene.index.ThreadedIndexingAndSearchingTestCase.runTest(ThreadedIndexingAndSearchingTestCase.java:519)
at 
org.apache.lucene.search.TestNRTManager.testNRTManager(TestNRTManager.java:53)
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:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at org.junit.rules.RunRules.evaluate(RunRules.java:18)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
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.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at 
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at 
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)




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



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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

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

Robert Muir commented on SOLR-3204:
---

{quote}
It's 5 classes it looks like - and it's Apache licensed and there is no release
- can't we simply suck this into our code base with a readme and JIRA about
removing it and switching to a release when one occurs? Get the whole
dependency thing right out of Maven's claws.
{quote}

Yes while this is the case, and as Emmanuel states, the purpose of his patch,
its not a scalable solution in general.
Its also expensive to fork software... there is always the danger that we then
become out-of-sync and never sync back up.

(feel free to hit me, for Uwe's example of snowball, which is a perfect example)

What about the other cases that fall into this same 'maven namespace' category,
e.g. the UIMA case for example?

How to fix the general problem? Thats why I think that the only proper way to
fix the bug is to attack it at the heart:
Thats the fact that for maven project A to depend upon project B that is not in
maven, maven project A must publish some fake maven release of project B.

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, solr-csv.patch

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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

And for the record, i want to withdraw my opposition to Emmanuel's patch.

I still feel strongly this doesn't solve the 'real problem', but if it makes 
the commons-csv developers happy, lets do it.

Though I think its fair to say I will speak up if i see any commits/local 
modifications to this, because ultimately I want
to see us depending upon a released version of this jar file.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Mark Miller commented on SOLR-3204:
---

bq. That was the purpose of my patch Mark 

+1 - I think this is the way to go, I just haven't understood any objections to 
it yet.

bq. I still feel strongly this doesn't solve the 'real problem',

Hate to sound like a broken record jerk, but again I think the real problem is 
our support of Maven :)

I don't see how, short of dropping internal Maven support, we solve the real 
problem. And barring a full glorious solution, this is a small and simple thing 
we can do that makes the commons guys happy. If all of a sudden we are 
bombarded by issues like these, I guess we can burn that bridge later. And drop 
Maven :)

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler commented on SOLR-3204:
-

{quote}
I still feel strongly this doesn't solve the 'real problem', but if it makes 
the commons-csv developers happy, lets do it.

Though I think its fair to say I will speak up if i see any commits/local 
modifications to this, because ultimately I want
to see us depending upon a released version of this jar file.
{quote}

To prevent this I would prefer jarjar, its not risky here at all (and also not 
for other usitility libs from commons). I am already plaing around with that. 
What I did here was repackage the JAR file and used a simple serach/replace on 
our source files to refer to new package name. Not even maven config has to be 
changedm Steven Rowe can publish the solr-commons-csv.jar as he likes.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

Uwe: maybe we should do it just for this case (rather than offering a general 
solution?)

Basically what i'm trying to say is that the general problem is complex, I 
think there are enough examples (jetty, carrot2, uima, etc)
that fall in this category that aren't really solved by jarjar. I think we 
either need to solve this issue as a 'case-by-case' for commons-csv,
or fix the entire problem (which definitely, definitely, certainly, without a 
doubt, involves fixing maven).

But to be practical, lets come up with something so that commons-csv developers 
are happy and can issue a release (which we can then depend upon).

Keeping in mind that this is supposed to be a 3.6 minor release, can we apply 
the jarjar solution *only* to commons-csv?
I feel the other situations are more dangerous and I think we should be 
careful, but at the same time we should address
their concerns and put ourselves in a situation where we don't end out 
'forking' it... I don't want to see that.


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] Lucene-Solr-tests-only-trunk-java7 - Build # 1904 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1904/

1 tests failed.
REGRESSION:  
org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded

Error Message:
expected:500 but was:400

Stack Trace:
junit.framework.AssertionFailedError: expected:500 but was:400
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at 
org.apache.solr.client.solrj.LargeVolumeTestBase.query(LargeVolumeTestBase.java:70)
at 
org.apache.solr.client.solrj.LargeVolumeTestBase.testMultiThreaded(LargeVolumeTestBase.java:61)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)




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



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

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Mark Miller commented on SOLR-3204:
---

bq. can we apply the jarjar solution only to commons-csv?

+1

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3212) Make response writers available at a core level, not just within a core

2012-03-07 Thread Erik Hatcher (Created) (JIRA)

Make response writers available at a core level, not just within a core
---

 Key: SOLR-3212
 URL: https://issues.apache.org/jira/browse/SOLR-3212
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher
Priority: Minor
 Fix For: 4.0


There's a hack that allows multicore handlers (like the CoreAdminHandler) to 
use a default built-in list (SolrCore.DEFAULT_RESPONSE_WRITERS) of response 
writers, but it makes it impossible to use a custom response writer.  Only 
individual core requests can use custom response writers.

Somehow response writers should be allowed to be registered above cores.  
(maybe a bigger topic in making other capabilities of Solr available across 
cores rather than core-specific?   Or maybe just specific to response writers?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Resolved] (SOLR-3162) Continue work on new admin UI

2012-03-07 Thread Erick Erickson (Resolved) (JIRA)


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

Erick Erickson resolved SOLR-3162.
--

   Resolution: Fixed
Fix Version/s: 4.0

r: 1298010

I folded SOLR-3181 into this commit.

 Continue work on new admin UI
 -

 Key: SOLR-3162
 URL: https://issues.apache.org/jira/browse/SOLR-3162
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis, web gui
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
 Fix For: 4.0

 Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, 
 SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, 
 SOLR-3162.patch, SOLR-3162.patch


 There have been more improvements to how the new UI works, but the current 
 open bugs are getting hard to keep straight. This is the new catch-all JIRA 
 for continued improvements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Uwe Schindler (Issue Comment Edited) (JIRA)


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

Steven Rowe commented on SOLR-3204:
---

bq. I think there are enough examples (jetty, carrot2, uima, etc) [...]

We are not currently publishing third party solr-uima-* artifacts, though we 
have in the past (versions prior to 3.5.0).


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Resolved] (SOLR-3181) New Admin UI, allow user to somehow cut/paste all the old Zookeeper info.

2012-03-07 Thread Erick Erickson (Resolved) (JIRA)

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

Erick Erickson resolved SOLR-3181.
--

Resolution: Fixed
Fix Version/s: 4.0

Fixed as part of SOLR-3162
r: 1298010

New Admin UI, allow user to somehow cut/paste all the old Zookeeper info.
---

Key: SOLR-3181
URL: https://issues.apache.org/jira/browse/SOLR-3181
Project: Solr
Issue Type: Improvement
Components: web gui
Affects Versions: 4.0
Environment: n/a
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Fix For: 4.0

Attachments: SOLR-3181.patch, SOLR-3181.patch

When tracking down issues with ZK, the devs ask about various bits of data
from the cloud pages. It would be convenient to be able to just capture all
the data from the old /solr/admin/zookeeper.jsp page in the admin interface
to be able to send it to anyone debugging the info.
Perhaps just a get debug info for Apache. Or even more cool copy debug
info to clipboard if that's possible. Is this just the raw data that the
cloud view is manipulating? It doesn't have to be pretty although indentation
would be nice.

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

[jira] [Updated] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated SOLR-3204:


Attachment: solr-commons-csv-1.0-SNAPSHOT-r966014.jar
rule.txt
SOLR-3204.patch

Here the patch and the transformed JAR file (and renamed).

What I did:
- copy the original JAR file to a folder
- place jarjar-1.2.jar somewhere
- edit the rules.txt file and change package names
- run java -jar jarjar-1.2.jar process rule.txt 
commons-csv-1.0-SNAPSHOT-r966014.jar solr-commons-csv-1.0-SNAPSHOT-r966014.jar

All tests pass and the supplied JAR file could be published in maven with the 
name sarowe gave it.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3162) Continue work on new admin UI

2012-03-07 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-3162:
--

OK, let's use different/new JIRAs to continue UI development

 Continue work on new admin UI
 -

 Key: SOLR-3162
 URL: https://issues.apache.org/jira/browse/SOLR-3162
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis, web gui
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
 Fix For: 4.0

 Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, 
 SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, 
 SOLR-3162.patch, SOLR-3162.patch


 There have been more improvements to how the new UI works, but the current 
 open bugs are getting hard to keep straight. This is the new catch-all JIRA 
 for continued improvements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler edited comment on SOLR-3204 at 3/7/12 4:36 PM:
-

Here the patch and the transformed JAR file (and renamed). Most of the patch is 
my rename of the JAR file to solr- prefix. Code changes is 5 lines of import 
statements!

What I did:
- copy the original JAR file to a folder
- place jarjar-1.2.jar somewhere
- edit the rules.txt file and change package names
- run java -jar jarjar-1.2.jar process rule.txt 
commons-csv-1.0-SNAPSHOT-r966014.jar solr-commons-csv-1.0-SNAPSHOT-r966014.jar
- place the resulting jar file in solr/core/lib (remove the old one before) and 
commit it like any other bundled artifact :-)

All tests pass and the supplied JAR file could be published in maven with the 
name sarowe gave it.

  was (Author: thetaphi):
Here the patch and the transformed JAR file (and renamed).

What I did:
- copy the original JAR file to a folder
- place jarjar-1.2.jar somewhere
- edit the rules.txt file and change package names
- run java -jar jarjar-1.2.jar process rule.txt 
commons-csv-1.0-SNAPSHOT-r966014.jar solr-commons-csv-1.0-SNAPSHOT-r966014.jar

All tests pass and the supplied JAR file could be published in maven with the 
name sarowe gave it.
  
 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

Thanks Uwe: i support your change. I think it is the best compromise.

it seems to me, because the jar is pre-jar-jar'ed we don't fall into various 
IDE configuration conflicts either right? Its just as easy for developers to 
configure 
their workspace (ant eclipse, ant idea)

+1


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Steven Rowe commented on SOLR-3204:
---

+1 for Uwe's JarJar fix.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler commented on SOLR-3204:
-

The keep line is not even needed in the rules.txt. There is one small issue: 
The resulting JAR file contains an empty org.apache.commons folder and some 
maven relicts (die,die,die), but thats minor.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3212) Make response writers available cross-core, not just within a core

2012-03-07 Thread Erik Hatcher (Updated) (JIRA)


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

Erik Hatcher updated SOLR-3212:
---

Summary: Make response writers available cross-core, not just within a core 
 (was: Make response writers available at a core level, not just within a core)

 Make response writers available cross-core, not just within a core
 --

 Key: SOLR-3212
 URL: https://issues.apache.org/jira/browse/SOLR-3212
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher
Priority: Minor
 Fix For: 4.0


 There's a hack that allows multicore handlers (like the CoreAdminHandler) to 
 use a default built-in list (SolrCore.DEFAULT_RESPONSE_WRITERS) of response 
 writers, but it makes it impossible to use a custom response writer.  Only 
 individual core requests can use custom response writers.
 Somehow response writers should be allowed to be registered above cores.  
 (maybe a bigger topic in making other capabilities of Solr available across 
 cores rather than core-specific?   Or maybe just specific to response 
 writers?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3855) TestStressNRT failures (reproducible)


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

Dawid Weiss commented on LUCENE-3855:
-

I began to think it's the Java version/ jvm bug that is causing these, but 
doesn't seem like it. Ran with the newest JRE 1.6:
{noformat}

junit-sequential:
[junit] Testsuite: org.apache.lucene.index.TestStressNRT
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 9.536 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
-Dtestmethod=test 
-Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
-Dargs=-Dfile.encoding=UTF-8
[junit] NOTE: test params are: codec=Lucene3x, 
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
timezone=US/East-Indiana
[junit] NOTE: all tests run in this JVM:
[junit] [TestStressNRT]
[junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_31 
(64-bit)/cpus=2,threads=1,free=95936736,total=148307968
[junit] -  ---
[junit] Testcase: test(org.apache.lucene.index.TestStressNRT):  FAILED
[junit] info=_gx(4.0):C9/7 isn't live
[junit] junit.framework.AssertionFailedError: info=_gx(4.0):C9/7 isn't live
[junit] at 
org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
[junit] at 
org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
[junit] at 
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
[junit] at 
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
[junit] at 
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
[junit] at 
org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:408)
[junit] at 
org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:380)
[junit] at 
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
[junit] at 
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit] at 
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
[junit] at 
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
[junit] at 
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
[junit] at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestStressNRT FAILED
{noformat}

 TestStressNRT failures (reproducible)
 -

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 4.0

 Attachments: output1.log, output2.log, output3.log, output4.log


 Build server logs. Reproduces on at least two machines.
 {noformat}
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
 -Dtestmethod=test 
 -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
 -Dargs=-Dfile.encoding=UTF-8
 [junit] NOTE: test params are: codec=Lucene3x, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
 timezone=Etc/GMT+1
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestStressNRT]
 [junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
 (64-bit)/cpus=2,threads=1,free=74960064,total=135987200
 [junit] -  ---
 [junit] Testcase: test(org.apache.lucene.index.TestStressNRT):Caused 
 an ERROR
 [junit] MockDirectoryWrapper: cannot close: there are still open files: 
 {_ng.cfs=8}
 [junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
 there are still open files: {_ng.cfs=8}
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
 [junit]   at 
 org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
 [junit]   at

[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8

2012-03-07 Thread Shawn Heisey (Commented) (JIRA)

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

Shawn Heisey commented on SOLR-3159:

I asked this on the mailing list, got zero response. I would like to know if
there are any good reasons to upgrade to Jetty 8 with an older release,
specifically 3.5.0. Also, the Jetty 8 distribution has a fair number of config
files in etc, but the example Solr only has jetty.xml and webdefault.xml. What
sort of recommendations do you have as far as config changes when upgrading?

I am using the JDK, so I would I be OK with the presence of JSP in the
pre-trunk version? Solr is not directly reachable from the outside world, it
is used on the internal network by our web application.

Upgrade to Jetty 8
--

Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority: Minor
Fix For: 4.0

Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is equivalent,
I think we should switch to Jetty 8.

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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12647 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12647/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=94 closes=93

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=94 
closes=93
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)




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



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

[jira] [Updated] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated SOLR-3204:


Attachment: apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar
SOLR-3204.patch
rule.txt

Updated patch to make it mor consistent with the naming conventions of Solr. 

I think we should do the same for the other file in lib: noggit

Steven Rowe: What other modified JARs do we have that are republished through 
maven?

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-commons-csv-1.0-SNAPSHOT-r966014.jar, solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated SOLR-3204:


Attachment: (was: solr-commons-csv-1.0-SNAPSHOT-r966014.jar)

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Dawid Weiss commented on SOLR-3204:
---

Don't jarjar Carrot2, please. We are plugging in our commercial clustering 
engine into Solr via Carrot2 controllers so if you change package namespace we 
will no longer be able to do it.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3838) IndexWriter.maybeMerge() removes deleted documents from index (Lucene 3.1.0 to 3.5.0)

2012-03-07 Thread Michael McCandless (Commented) (JIRA)


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

Michael McCandless commented on LUCENE-3838:


bq. of course this happens in version 3.1.0 as stated in the title (in 
parentheses).

Sorry, what I meant was Lucene has, forever, removed deleted docs
during natural merges (as well as forced merges); I'm not sure why
in 3.0.2 you're seeing otherwise...

bq. Actually, it has never been stated that this is an internal implementation 
detail (if I can remember correctly).

I don't know whether this is officially documented anywhere, but it
comes up every so often on the lists and the answer is always don't
rely on Lucene's docID... or, rather rely on docID at your own risk.

bq. Anyway, we already have an ID field but we can't rely on it for long 
running operations.

I didn't fully understand why you can't use your ID field for long
running operations...

bq. I only don't understand if we will have to wait for a Lucene 4.0 release 
for a custom codec implementation 

You'd have to use Lucene trunk (not yet released) to work with codecs.

bq. If I need to implement it for trunk than can you please give me a starting 
point where to begin from?

Start here I think?

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

EG, get a trunk checkout, browse trunk's javadocs, look @ the test cases, etc.

bq. Also, can this approach differentiate between maybeMerge() and forceMerge().

Maybe... eg a MergePolicy/Scheduler knows if a given merge request was
forced or not.


 IndexWriter.maybeMerge() removes deleted documents from index (Lucene 3.1.0 
 to 3.5.0)
 -

 Key: LUCENE-3838
 URL: https://issues.apache.org/jira/browse/LUCENE-3838
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
 Environment: Windows, Linux, OSX
Reporter: Ivan Stojanovic
Priority: Blocker
  Labels: api-change
 Attachments: TempTest.java


 My company uses Lucene for high performance, heavy loaded farms of 
 translation repositories with hundreds of simultaneous 
 add/delete/update/search/retrieve threads. In order to support this complex 
 architecture beside other things and tricks used here I rely on docId-s being 
 unchanged until I ask that explicitly (using IndexWriter.optimize() - 
 IndexWriter.forceMerge()).
 For this behavior LogMergePolicy is used.
 This worked fine until we raised the Lucene version from 3.0.2 to 3.5.0. 
 Until version 3.1.0 merge triggerred by IndexWriter.addDocument() didn't 
 expunge deleted documents ensuring that docId-s stayed unchanged and making 
 some critical jobs possible without impact on index size. 
 IndexWriter.optimize() did the actual deleted documents removal.
 From Lucene version 3.1.0 IndexWriter.maybeMerge() does the same thing as 
 IndexWriter.forceMerge() regarding deleted documents. There is no difference. 
 This leads to unpredictable internal index structure changes during simple 
 document add (and possible delete) operations and in undefined point in time. 
 I looked into the Lucene source code and can definitely confirm this.
 This issue makes our Lucene client code totally unusable.
 Solution steps:
 1) add a flag somewhere that will control whether the deleted documents 
 should be removed in maybeMerge(). Note that this is only a half of what we 
 need here.
 2) make forceMerge() always remove deleted documents no matter if 
 maybeMerge() removes them or not. Alternatively, there can be another 
 parameter added to forceMerge() that will also tell if deleted documents 
 should be removed from index or not.
 The sample JUnit code that can replicate this issue is added below.
 public class TempTest {
 private Analyzer _analyzer = new KeywordAnalyzer();
 @Test
 public void testIndex() throws Exception {
   File indexDir = new File(sample-index);
   if (indexDir.exists()) {
   indexDir.delete();
   }
   FSDirectory index = FSDirectory.open(indexDir);
   Document doc;
   IndexWriter writer = createWriter(index, true);
   try {
   doc = new Document();
   doc.add(new Field(field, text0, Field.Store.YES,
   Field.Index.ANALYZED));
   writer.addDocument(doc);
   doc = new Document();
   doc.add(new Field(field, text1, Field.Store.YES,
   Field.Index.ANALYZED));
   writer.addDocument(doc);
   doc = new Document();
   doc.add(new Field(field, text2, Field.Store.YES,
   Field.Index.ANALYZED));
   writer.addDocument(doc);
   writer.commit();
   } finally {
   writer.close();

[jira] [Commented] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Steven Rowe (Issue Comment Edited) (JIRA)


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

Steven Rowe commented on SOLR-3204:
---

bq. Steven Rowe: What other modified JARs do we have that are republished 
through maven?

For branch_3x:

||module||jar||
|Lucene 
benchmark|{{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ-1257.jar}}|
|Solr clustering|{{solr/contrib/clustering/carrot2-core-3.5.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/jsonic-1.2.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/langdetect-r111-java5.jar}}|
|Solr core|{{solr/lib/apache-solr-noggit-r1099557.jar}}|
|Solr core|{{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}}|

Trunk is the same, except that the carrot2-core jar is no longer required (it's 
required on branch_3x because it's a specially Java5-compiled jar, but no 
longer on trunk/4.0, which requires Java 6, and so can use the Maven central 
artifact.)




 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Issue Comment Edited] (SOLR-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Steven Rowe edited comment on SOLR-3204 at 3/7/12 5:23 PM:
---

bq. Steven Rowe: What other modified JARs do we have that are republished 
through maven?

For branch_3x:

||module||jar||
|Lucene 
benchmark|{{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ\-1257.jar}}|
|Solr clustering|{{solr/contrib/clustering/carrot2-core-3.5.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/jsonic-1.2.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/langdetect-r111-java5.jar}}|
|Solr core|{{solr/lib/apache-solr-noggit-r1099557.jar}}|
|Solr core|{{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}}|

Trunk is the same, except that the carrot2-core jar is no longer required (it's 
required on branch_3x because it's a specially Java5-compiled jar, but no 
longer on trunk/4.0, which requires Java 6, and so can use the Maven central 
artifact.)




  was (Author: steve_rowe):
bq. Steven Rowe: What other modified JARs do we have that are republished 
through maven?

For branch_3x:

||module||jar||
|Lucene 
benchmark|{{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ-1257.jar}}|
|Solr clustering|{{solr/contrib/clustering/carrot2-core-3.5.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/jsonic-1.2.0.jar}}|
|Solr langid|{{solr/contrib/langid/lib/langdetect-r111-java5.jar}}|
|Solr core|{{solr/lib/apache-solr-noggit-r1099557.jar}}|
|Solr core|{{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}}|

Trunk is the same, except that the carrot2-core jar is no longer required (it's 
required on branch_3x because it's a specially Java5-compiled jar, but no 
longer on trunk/4.0, which requires Java 6, and so can use the Maven central 
artifact.)



  
 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler commented on SOLR-3204:
-

According to Steven, we don't republish them so there is no need to do this.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Uwe Schindler commented on SOLR-3204:
-

For carrot: If you can just compile carrot with Java 5 and produce Java 5 JARs, 
why does Dawid/Carrot not do this? A Java 6 class/jar file is not really useful 
if just the version number of the file header is different...

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Assigned] (LUCENE-3837) A modest proposal for updateable fields

2012-03-07 Thread Andrzej Bialecki (Assigned) (JIRA)

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

Andrzej Bialecki reassigned LUCENE-3837:
-

Assignee: Andrzej Bialecki

A modest proposal for updateable fields
---

Key: LUCENE-3837
URL: https://issues.apache.org/jira/browse/LUCENE-3837
Project: Lucene - Java
Issue Type: New Feature
Components: core/index
Affects Versions: 4.0
Reporter: Andrzej Bialecki
Assignee: Andrzej Bialecki

I'd like to propose a simple design for implementing updateable fields in
Lucene. This design has some limitations, so I'm not claiming it will be
appropriate for every use case, and it's obvious it has some performance
consequences, but at least it's a start...
This proposal uses a concept of overlays or stacked updates, where the
original data is not removed but instead it's overlaid with the new data. I
propose to reuse as much of the existing APIs as possible, and represent
updates as an IndexReader. Updates to documents in a specific segment would
be collected in an overlay index specific to that segment, i.e. there would
be as many overlay indexes as there are segments in the primary index.
A field update would be represented as a new document in the overlay index .
The document would consist of just the updated fields, plus a field that
records the id in the primary segment of the document affected by the update.
These updates would be processed as usual via secondary IndexWriter-s, as
many as there are primary segments, so the same analysis chains would be
used, the same field types, etc.
On opening a segment with updates the SegmentReader (see also LUCENE-3836)
would check for the presence of the overlay index, and if so it would open
it first (as an AtomicReader? or it would open individual codec format
readers? perhaps it should load the whole thing into memory?), and it would
construct an in-memory map between the primary's docId-s and the overlay's
docId-s. And finally it would wrap the original format readers with overlay
readers, initialized also with the id map.
Now, when consumers of the 4D API would ask for specific data, the overlay
readers would first re-map the primary's docId to the overlay's docId, and
check whether overlay data exists for that docId and this type of data (e.g.
postings, stored fields, vectors) and return this data instead of the
original. Otherwise they would return the original data.
One obvious performance issue with this appraoch is that the sequential
access to primary data would translate into random access to the overlay
data. This could be solved by sorting the overlay index so that at least the
overlay ids increase monotonically as primary ids do.
Updates to the primary index would be handled as usual, i.e. segment merges,
since the segments with updates would pretend to have no overlays) would just
work as usual, only the overlay index would have to be deleted once the
primary segment is deleted after merge.
Updates to the existing documents that already had some fields updated would
be again handled as usual, only underneath they would open an IndexWriter on
the overlay index for a specific segment.
That's the broad idea. Feel free to pipe in - I started some coding at the
codec level but got stuck using the approach in LUCENE-3836. The approach
that uses a modified SegmentReader seems more promising.

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

[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji

2012-03-07 Thread Michael McCandless (Commented) (JIRA)

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

Michael McCandless commented on LUCENE-3767:

bq. I haven't backported the test for PositionLengthAttribute since the
structure seems very different in branch_3x. Perhaps this is something we could
look to as we start using PositionLength in more of the other analyzers?

Hmm you mean TestSimpleAttributeImpl? I think that's fine. We'll
improve testing of pos length as we make more tokenizers/filters
graphs...

bq. Does the svn:mergeinfo look okay in the patch?

Hmm looks spooky... there was a trick for this... (and I know it's
hard to merge back since the path changed in trunk). Maybe do svn
propdel svn:mergeinfo on all affected files, and then at the top level
you can just do an svn merge --record-only to update toplevel
mergeinfo?

bq. There will be some minor discrepancies between trunk and branch_3x with
regards to Set? and CharArraySet types. Perhaps we should use CharArraySet on
across the board here in the future?

This was from LUCENE-3765; I think it's OK to require
CharArraySet to Kuromoji...

Looks like the added files are not included in the patch (eg
RollingCharBuffer)... if you're using svn = 1.7, you can run svn
diff --show-copies-as-adds maybe? Or, use
dev-tools/scripts/diffSources.py... but I don't think it's
really necessary before committing...

Otherwise patch looks great!

Explore streaming Viterbi search in Kuromoji

Key: LUCENE-3767
URL: https://issues.apache.org/jira/browse/LUCENE-3767
Project: Lucene - Java
Issue Type: Improvement
Components: modules/analysis
Reporter: Michael McCandless
Assignee: Christian Moen
Fix For: 3.6, 4.0

Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767_branch_3x.patch,
SolrXml-5498.xml, compound_diffs.txt

I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.
One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...

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

[jira] [Commented] (LUCENE-3778) Create a grouping convenience class

2012-03-07 Thread Michael McCandless (Commented) (JIRA)

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

Michael McCandless commented on LUCENE-3778:

Patch looks good!

bq. Also grouping by docblock and grouping features like allGroups and
groupHead don't work in a normal sharded environment (unless you partition the
groups properly).

Doc block grouping should work well in a sharded env right? As long
as you send the whole block to a single shard...

bq. This usage is very different then non distributed grouping, that is why I
think it is better to have a separate grouping convenience class for
distributed grouping (DistributedGroupSearch?).

OK I agree.

{quote}
bq. Maybe you should pass the groupSort, groupsOffset, groupsLimit to the
search method (instead of setters)?

Maybe we just should have defaults for these options? Sort.RELEVANCE, 0 and 10?
{quote}

Well, I was trying to mirror IndexSearcher.search (for lack of any
other guidance on what should be required arg to ctor, optional via
setter or required arg to .search).

So, yeah, I think default to Sort.RELEVANCE is good? Maybe we have 1
search method doing that and another taking the GroupSort?

I think it's strange to have a default for the top N groups (10)? I
think app should have to specify that as an arg to search...

Should we name it GroupSearch? GroupedSearch? GroupingSearch...? I don't
have a strong preference... I think GroupingSearch (current name) is OK?

Create a grouping convenience class
---

Key: LUCENE-3778
URL: https://issues.apache.org/jira/browse/LUCENE-3778
Project: Lucene - Java
Issue Type: Improvement
Components: modules/grouping
Reporter: Martijn van Groningen
Attachments: LUCENE-3778.patch, LUCENE-3778.patch

Currently the grouping module has many collector classes with a lot of
different options per class. I think it would be a good idea to have a
GroupUtil (Or another name?) convenience class. I think this could be a
builder, because of the many options
(sort,sortWithinGroup,groupOffset,groupCount and more) and implementations
(term/dv/function) grouping has.

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

[jira] [Resolved] (SOLR-3079) Backport of Solr-1431 (CommComponent abstracted)

2012-03-07 Thread Erick Erickson (Resolved) (JIRA)


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

Erick Erickson resolved SOLR-3079.
--

   Resolution: Fixed
Fix Version/s: 3.6

r: 1298032

 Backport of Solr-1431 (CommComponent abstracted)
 

 Key: SOLR-3079
 URL: https://issues.apache.org/jira/browse/SOLR-3079
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 3.5
Reporter: Greg Bowyer
Assignee: Erick Erickson
 Fix For: 3.6

 Attachments: 0001-Initial-backport-of-solr-cloud-ShardHandler.patch, 
 SOLR-3079.patch, SOLR-3079.patch, SOLR-3079.patch


 Initial attempt at backporting the work done for Solr-1431 into the 3.x series

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3079) Backport of Solr-1431 (CommComponent abstracted)

2012-03-07 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-3079:
--

P.S. Thanks Greg!

 Backport of Solr-1431 (CommComponent abstracted)
 

 Key: SOLR-3079
 URL: https://issues.apache.org/jira/browse/SOLR-3079
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 3.5
Reporter: Greg Bowyer
Assignee: Erick Erickson
 Fix For: 3.6

 Attachments: 0001-Initial-backport-of-solr-cloud-ShardHandler.patch, 
 SOLR-3079.patch, SOLR-3079.patch, SOLR-3079.patch


 Initial attempt at backporting the work done for Solr-1431 into the 3.x series

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3182) If there is only one core, let it be the default without specifying a default in solr.xml

2012-03-07 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-3182:
--

Do we want to carry this forward for 3.x? If so, we need to get consensus real 
soon now since there's a movement to cut a 3.6 (the last 3x release planned?) 
in 10 days or so.

I've assigned it to myself just as a placeholder, if someone else wants to go 
ahead and take this, please feel free.

Or does all the SolrCloud stuff make this something we don't want to deal with 
(in which case there never will be a 3.x way to handle this)...

Or does it make sense to do this for 3.6 and not try to move it into trunk?

 If there is only one core, let it be the default without specifying a default 
 in solr.xml
 -

 Key: SOLR-3182
 URL: https://issues.apache.org/jira/browse/SOLR-3182
 Project: Solr
  Issue Type: Improvement
  Components: multicore
Affects Versions: 3.6, 4.0
Reporter: Russell Black
Priority: Minor
  Labels: patch
 Attachments: SOLR-3182-default-core.patch

   Original Estimate: 10m
  Remaining Estimate: 10m

 Our particular need for this is as follows.  We operate in a sharded 
 environment with one core per server.  Each shard also acts as a collator.  
 We want to use a hardware load balancer to choose which shard will do the 
 collation for each query.  But in order to do that, each server's single core 
 would have to carry the same name so that it could be accessed by the same 
 url across servers.  However we name the cores by their shard number 
 (query0,query1,...) because it parallels with the way we name our 
 indexing/master cores (index0, index1,...).  This naming convention also 
 gives us the flexibility of moving to a multicore environment in the future 
 without having to rename the cores, although admittedly that would complicate 
 load balancing.  
 In a system with a large number of shards and the anticipation of adding more 
 going forward, setting a defaultCoreName attribute in each solr.xml file 
 becomes inconvenient, especially since there is no Solr admin API for setting 
 defaultCoreName.  It would have to be done by hand or with some automated 
 tool we would write in house.  Even if there were an API, logically it seems 
 unnecessary to have to declare the only core to be the default. 
 Fortunately this behavior can be implemented with the following simple patch:
 {code}
 Index: solr/core/src/java/org/apache/solr/core/CoreContainer.java
 ===
 --- solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (revision 1295229)
 +++ solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (working copy)
 @@ -870,6 +870,10 @@
}
  
private String checkDefault(String name) {
 +// if there is only one core, let it be the default without specifying a 
 default in solr.xml
 +if (defaultCoreName.trim().length() == 0  name.trim().length() == 0  
 cores.size() == 1) {
 +  return cores.values().iterator().next().getName();
 +}
  return name.length() == 0  || defaultCoreName.equals(name) || 
 name.trim().length() == 0 ?  : name;
} 
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] [Assigned] (SOLR-3182) If there is only one core, let it be the default without specifying a default in solr.xml

2012-03-07 Thread Erick Erickson (Assigned) (JIRA)


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

Erick Erickson reassigned SOLR-3182:


Assignee: Erick Erickson

 If there is only one core, let it be the default without specifying a default 
 in solr.xml
 -

 Key: SOLR-3182
 URL: https://issues.apache.org/jira/browse/SOLR-3182
 Project: Solr
  Issue Type: Improvement
  Components: multicore
Affects Versions: 3.6, 4.0
Reporter: Russell Black
Assignee: Erick Erickson
Priority: Minor
  Labels: patch
 Attachments: SOLR-3182-default-core.patch

   Original Estimate: 10m
  Remaining Estimate: 10m

 Our particular need for this is as follows.  We operate in a sharded 
 environment with one core per server.  Each shard also acts as a collator.  
 We want to use a hardware load balancer to choose which shard will do the 
 collation for each query.  But in order to do that, each server's single core 
 would have to carry the same name so that it could be accessed by the same 
 url across servers.  However we name the cores by their shard number 
 (query0,query1,...) because it parallels with the way we name our 
 indexing/master cores (index0, index1,...).  This naming convention also 
 gives us the flexibility of moving to a multicore environment in the future 
 without having to rename the cores, although admittedly that would complicate 
 load balancing.  
 In a system with a large number of shards and the anticipation of adding more 
 going forward, setting a defaultCoreName attribute in each solr.xml file 
 becomes inconvenient, especially since there is no Solr admin API for setting 
 defaultCoreName.  It would have to be done by hand or with some automated 
 tool we would write in house.  Even if there were an API, logically it seems 
 unnecessary to have to declare the only core to be the default. 
 Fortunately this behavior can be implemented with the following simple patch:
 {code}
 Index: solr/core/src/java/org/apache/solr/core/CoreContainer.java
 ===
 --- solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (revision 1295229)
 +++ solr/core/src/java/org/apache/solr/core/CoreContainer.java
 (working copy)
 @@ -870,6 +870,10 @@
}
  
private String checkDefault(String name) {
 +// if there is only one core, let it be the default without specifying a 
 default in solr.xml
 +if (defaultCoreName.trim().length() == 0  name.trim().length() == 0  
 cores.size() == 1) {
 +  return cores.values().iterator().next().getName();
 +}
  return name.length() == 0  || defaultCoreName.equals(name) || 
 name.trim().length() == 0 ?  : name;
} 
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions

2012-03-07 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-2124:
--

A lot has changed since this was submitted, see: SOLR-2191 and associated. Is 
this still an issue? I confess I'm not quite sure how to reproduce it to test 
(hint, hint)

 SEVERE exceptions are being logged for expected PingRequestHandler 
 SERVICE_UNAVAILABLE exceptions
 -

 Key: SOLR-2124
 URL: https://issues.apache.org/jira/browse/SOLR-2124
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 3.6, 4.0


 As reported by a user, if you use the PingRequestHandler, and the 
 corrisponding helthcheck file doesn't exist (and expected situation when a 
 server is out of rotation) Solr is logging a SEVERE error...
 {noformat}
 SEVERE: org.apache.solr.common.SolrException: Service disabled
   at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 {noformat}
 This is in spite of hte fact that PingRequestHandler explicitly sets the 
 alreadyLogged boolean to true in the SolrException constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package


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

Robert Muir commented on SOLR-3204:
---

Well the carrot is similar to the uima case, in both cases we have their 
committers also as committers working
on integrations within on our project, and they have voiced no problem with how 
things work so far, so why break it?


 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions

2012-03-07 Thread James Dyer (Commented) (JIRA)


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

James Dyer commented on SOLR-2124:
--

I think this is still a problem.  I have a snapshot from 1/31 (post-2191 and 
its children) and it still logs a whole stack trace every time the load 
balancer pings it, if the service-enabled file is missing.  This is a pretty 
big annoyance for me because I often use a live, load-balanced dev 
environment to test new versions with the testing node taken out using this 
ping feature.  If nobody else does anything, I'll likely be annoyed enough to 
fix it eventually.

 SEVERE exceptions are being logged for expected PingRequestHandler 
 SERVICE_UNAVAILABLE exceptions
 -

 Key: SOLR-2124
 URL: https://issues.apache.org/jira/browse/SOLR-2124
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Erick Erickson
 Fix For: 3.6, 4.0


 As reported by a user, if you use the PingRequestHandler, and the 
 corrisponding helthcheck file doesn't exist (and expected situation when a 
 server is out of rotation) Solr is logging a SEVERE error...
 {noformat}
 SEVERE: org.apache.solr.common.SolrException: Service disabled
   at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
   at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 {noformat}
 This is in spite of hte fact that PingRequestHandler explicitly sets the 
 alreadyLogged boolean to true in the SolrException constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3720) OOM in TestBeiderMorseFilter.testRandom


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

Robert Muir commented on LUCENE-3720:
-

There is now a patch on CODEC-132 , I haven't had the time to try to 
apply-rebuild-test with it, but it seems like the right fix.

 OOM in TestBeiderMorseFilter.testRandom
 ---

 Key: LUCENE-3720
 URL: https://issues.apache.org/jira/browse/LUCENE-3720
 Project: Lucene - Java
  Issue Type: Test
  Components: modules/analysis
Affects Versions: 3.6, 4.0
Reporter: Robert Muir

 This has been OOM'ing a lot... we should see why, its likely a real bug.
 ant test -Dtestcase=TestBeiderMorseFilter -Dtestmethod=testRandom 
 -Dtests.seed=2e18f456e714be89:310bba5e8404100d:-3bd11277c22f4591 
 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Michael McCandless (Commented) (JIRA)

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

Michael McCandless commented on SOLR-3204:
--

{quote}
How to fix the general problem? Thats why I think that the only proper way to
fix the bug is to attack it at the heart:
Thats the fact that for maven project A to depend upon project B that is not in
maven, maven project A must publish some fake maven release of project B.
{quote}

+1, this sums up the Maven issue.

But is it really true? Is there really no way to stop Maven from
making project A's private deps public? This is horribly invasive.

CLASSPATH polution is a separate, widespread, longstanding and very
real issue. I don't think jarjar'ing every dependency Solr (or our
modules, contribs, etc.) is a good general solution.

But I think it's OK in this case... progress not perfection. Your
patch looks good Uwe, thanks!

solr-commons-csv must not use the org.apache.commons.csv package

Key: SOLR-3204
URL: https://issues.apache.org/jira/browse/SOLR-3204
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
Fix For: 3.6

Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch,
apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt,
solr-csv.patch

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

[jira] [Resolved] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE

2012-03-07 Thread Michael McCandless (Resolved) (JIRA)


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

Michael McCandless resolved LUCENE-3831.


   Resolution: Fixed
Fix Version/s: 4.0
   3.6

Thanks Alan.

I couldn't provoke an NPE on 3.x but I still fixed SpanWeight to not pass on a 
null field to IR.norms.

 Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
 --

 Key: LUCENE-3831
 URL: https://issues.apache.org/jira/browse/LUCENE-3831
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.0
Reporter: Alan Woodward
Assignee: Michael McCandless
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: LUCENE-3831.patch, TestNullFieldAfterRegexpRewrite.java, 
 mindex-null-field.patch


 I found this when querying a MemoryIndex using a RegexpQuery wrapped by a 
 SpanMultiTermQueryWrapper.  If the regexp doesn't match anything in the 
 index, it gets rewritten to an empty SpanOrQuery with a null field value, 
 which then triggers the NPE.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3204) solr-commons-csv must not use the org.apache.commons.csv package

2012-03-07 Thread Ryan McKinley (Commented) (JIRA)


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

Ryan McKinley commented on SOLR-3204:
-

+1 thanks Uwe

bq. I don't think jarjar'ing every dependency Solr

The only jar files in question are snapshot/unreleased code.  The commons-csv 
problem is a non issue if we were using a released version.

 solr-commons-csv must not use the org.apache.commons.csv package
 

 Key: SOLR-3204
 URL: https://issues.apache.org/jira/browse/SOLR-3204
 Project: Solr
  Issue Type: Bug
  Components: Build
Affects Versions: 3.5
Reporter: Emmanuel Bourg
Priority: Blocker
 Fix For: 3.6

 Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, 
 apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, 
 solr-csv.patch


 The solr-commons-csv artifact reused the code from the Apache Commons CSV 
 project but the package wasn't changed to something else than 
 org.apache.commons.csv in the process. This creates a compatibility issue as 
 the Apache Commons team works toward an official release of Commons CSV. It 
 prevents Commons CSV from using its own org.apache.commons.csv package, or 
 forces the renaming of all the classes to avoid a classpath conflict.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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] Lucene-Solr-tests-only-trunk-java7 - Build # 1906 - Failure