[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12937 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12937/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch Error Message: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:819) at org.apache.lucene.util.LuceneTestCase.access$900(LuceneTestCase.java:138) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:676) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) 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.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:930) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:809) ... 28 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=91 closes=89 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 closes=89 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974) at junit.framework.TestResult.addError(TestResult.java:38) at junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51) at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41) at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97) at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:306) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244008#comment-13244008 ] Dawid Weiss commented on LUCENE-3930: - Looks good to me, Chris. Two minor things: 1) sourceDirectory and testSourceDirectory look like default values anyway? 2) there is a newer version of jsonic in maven repositories; don't know if this matters at all. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, LUCENE-3930_includetestlibs_excludeexamplexml.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch, pom.xml As mentioned on the ML thread: switch jars to ivy mechanism?. -- 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: ivy.
I've spent a little time on this but I couldn't get it to work. Ivy
doesn't seem to read the ~/.ivy2/ivysettings.xml by default and the
config in there, even if overriden, is hazy to me.
I'll just go with the flow.
Dawid
On Fri, Mar 30, 2012 at 10:44 PM, Greg Bowyer gbow...@fastmail.co.uk wrote:
You can get ivy to treat the local maven repo as a resolver host I think the
required config is along the lines of
%
resolvers
filesystem name=local-maven-2 m2compatible=true force=false
local=true
artifact
pattern=${gerald.repo.dir}/[organisation]/[module]/[revision]/[module]-[revision].[ext]/
ivy
pattern=${gerald.repo.dir}/[organisation]/[module]/[revision]/[module]-[revision].pom/
/filesystem
/resolvers
...
/settings
chain name=whatever dual=true
checkmodified=true changingPattern=.*SNAPSHOT
resolver ref=local-maven-2/
resolver ref=apache-snapshot/
resolver ref=maven2/
...
/chain
%
-- Greg
On 30/03/12 13:27, Dawid Weiss wrote:
But honestly, i have no idea how ivy works. its just like ant to me. i
just hack and hack and hack until it works.
You're a live randomized solver!
Dawid
-
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
[jira] [Issue Comment Edited] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244019#comment-13244019 ] Chris Male edited comment on LUCENE-3930 at 4/2/12 7:25 AM: Thanks for the review. bq. 1) sourceDirectory and testSourceDirectory look like default values anyway? Err.. yes, I used the pom the maintainer had started and forgot to pull those out. Will do. bq. 2) there is a newer version of jsonic in maven repositories; don't know if this matters at all. I will stick with the version used in the project. was (Author: cmale): bq. 1) sourceDirectory and testSourceDirectory look like default values anyway? Err.. yes, I used the pom the maintainer had started and forgot to pull those out. Will do. bq. 2) there is a newer version of jsonic in maven repositories; don't know if this matters at all. I will stick with the version used in the project. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, LUCENE-3930_includetestlibs_excludeexamplexml.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch, pom.xml As mentioned on the ML thread: switch jars to ivy mechanism?. -- 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-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244019#comment-13244019 ] Chris Male commented on LUCENE-3930: bq. 1) sourceDirectory and testSourceDirectory look like default values anyway? Err.. yes, I used the pom the maintainer had started and forgot to pull those out. Will do. bq. 2) there is a newer version of jsonic in maven repositories; don't know if this matters at all. I will stick with the version used in the project. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, LUCENE-3930_includetestlibs_excludeexamplexml.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch, pom.xml As mentioned on the ML thread: switch jars to ivy mechanism?. -- 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-3011) DIH MultiThreaded bug
[ https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244027#comment-13244027 ] Bernd Fehling commented on SOLR-3011: - It works with 3.5 but after applying the SOLR-3011 patch it fails. I know that threads will be removed with 4.0 but nevertheless it is helpful when loading tons of data on a multi CPU machine. I try to provide a unit test as new issue with reference to this issue. Stupid question, if threads will be removed with 4.0 does this mean that the redesign of dataimport is multi-threading by default so that no threads parameter is needed, or will it be sized down to single-thread? DIH MultiThreaded bug - Key: SOLR-3011 URL: https://issues.apache.org/jira/browse/SOLR-3011 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 3.5 Reporter: Mikhail Khludnev Assignee: James Dyer Priority: Minor Fix For: 3.6 Attachments: SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch, patch-3011-EntityProcessorBase-iterator.patch current DIH design is not thread safe. see last comments at SOLR-2382 and SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly it's a SOLR-2947 patch from 28th Dec. -- 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-3305) not able to index complete pdf file
not able to index complete pdf file --- Key: SOLR-3305 URL: https://issues.apache.org/jira/browse/SOLR-3305 Project: Solr Issue Type: Bug Affects Versions: 3.3 Environment: Ubuntu, apache tikka 1.0, apache solr 3.3.0 Reporter: manoj saini Hello Guys, I am using apache solr 3.3.0 with Tikka 1.0. I have pdf files which I am pushing into solr for conent searching. Apache solr is indexing pdf files and I can see them in apache solr admin interface for search. But the issue is apache solr is not indexing whole file content. It is indexing upto only limited size. Am I missing something, some configuration, or this is the behavior of apache solr? I have tried to update solrconfig.xml. I have updated ramBufferSizeMB, maxFieldLength. Thanks Manoj Saini -- 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] [Closed] (SOLR-3305) not able to index complete pdf file
[ https://issues.apache.org/jira/browse/SOLR-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-3305. - Resolution: Not A Problem Hi. Please ask questions on the Users mailing list, not here in the bug tracker. Please see http://wiki.apache.org/solr/UsingMailingLists not able to index complete pdf file --- Key: SOLR-3305 URL: https://issues.apache.org/jira/browse/SOLR-3305 Project: Solr Issue Type: Bug Affects Versions: 3.3 Environment: Ubuntu, apache tikka 1.0, apache solr 3.3.0 Reporter: manoj saini Hello Guys, I am using apache solr 3.3.0 with Tikka 1.0. I have pdf files which I am pushing into solr for conent searching. Apache solr is indexing pdf files and I can see them in apache solr admin interface for search. But the issue is apache solr is not indexing whole file content. It is indexing upto only limited size. Am I missing something, some configuration, or this is the behavior of apache solr? I have tried to update solrconfig.xml. I have updated ramBufferSizeMB, maxFieldLength. Thanks Manoj Saini -- 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-2696) ping.jsp throws unhandled exception type Throwable
[ https://issues.apache.org/jira/browse/SOLR-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244105#comment-13244105 ] Matthew Buckett commented on SOLR-2696: --- You can fix the error by just rethrowing the Throwable error in a RuntimeException. ping.jsp throws unhandled exception type Throwable Key: SOLR-2696 URL: https://issues.apache.org/jira/browse/SOLR-2696 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 3.3 Environment: myEclipse Blue v 8.6.1, but presumably this error would be flagged in any environment that checks JSPs Reporter: Jay R. Jaeger Priority: Trivial Labels: newbie, newdev The JSP ping.jsp throws an exception of type Throwable, but nowhere indicates it throws this exception. myEclipse Blue (and, I'd expect, just about any Eclipse JSP editor) flags this as an error. This is a bit annoying, as the error indication flag then percolates up thru the entire project in myEclipse. -- 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-1758) schema definition for configuration files (validation, XSD)
[
https://issues.apache.org/jira/browse/SOLR-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244106#comment-13244106
]
Jan Høydahl commented on SOLR-1758:
---
Perhaps under {{/solr/core/src/resources/validation/}} with individual schemas
for all known release versions of the files we want to validate:
{noformat}
solrconfig-LUCENE_31.xsd
solrconfig-LUCENE_32.xsd
solrconfig-LUCENE_33.xsd
solrconfig-LUCENE_34.xsd
solrconfig-LUCENE_35.xsd
solrconfig-LUCENE_36.xsd
solrconfig-LUCENE_40.xsd
schema-1.1.xsd
schema-1.2.xsd
schema-1.3.xsd
schema-1.4.xsd
schema-1.5.xsd
{noformat}
schema definition for configuration files (validation, XSD)
---
Key: SOLR-1758
URL: https://issues.apache.org/jira/browse/SOLR-1758
Project: Solr
Issue Type: New Feature
Reporter: Jorg Heymans
Labels: configuration, schema.xml, solrconfig.xml, validation,
xsd
Fix For: 4.0
Attachments: config-validation-20110523.patch
It is too easy to make configuration errors in Solr without getting warnings.
We should explore ways of validation configurations. See mailing list
discussion at http://search-lucene.com/m/h6xKf1EShE6
--
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-3306) Possibility to specify proxy settings for http-transport
Possibility to specify proxy settings for http-transport Key: SOLR-3306 URL: https://issues.apache.org/jira/browse/SOLR-3306 Project: Solr Issue Type: New Feature Components: Schema and Analysis Affects Versions: 3.5 Environment: OS agnostic Reporter: Peter Litsegård Fix For: 3.5 This is not an issue as such, rather it's a proposal for an enhancement. When using the Solr UIMA-plugin I run into connection timeout errors as our Solr-instance is running behind a firewall and the UIMA-plugin is unable to connect to, say, the Alchemy-API service. I've tried to specify JAVA_OPTS settings to no avail. It would be great if there would be a possibility to specify proxy settings in the solrconfig.xml file, thus making it possible to route http-calls through that proxy. -- 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-3940) When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole
[ https://issues.apache.org/jira/browse/LUCENE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244111#comment-13244111 ] Christian Moen commented on LUCENE-3940: I'm not familiar with the various considerations that were made with StandardTokenizer, but please allow me to share some comments anyway. Perhaps it's useful to distinguish between _analysis for information retrieval_ and _analysis for information extraction_ here? I like Michael's and Steven's idea of doing tokenization that doesn't discard any information. This is certainly useful in the case of _information extraction_. For example, if we'd like to extract noun-phrases based on part-of-speech tags, we don't want to conjoin tokens in case there's a punctuation character between two nouns (unless that punctuation character is a middle dot). Robert is of course correct that we generally don't want to index punctuation characters that occur in every document, so from an _information retrieval_ point of view, we'd like punctuation characters removed. If there's an established convention that Tokenizer variants discards punctuation and produces the terms that are meant to be directly searchable, it sounds like a good idea that we stick to the convention here as well. If there's no established convention, it seems useful that a Tokenizer would provide as much details as possible with text being input and leave downstream Filters/Analyzers to remove whatever is suitable based on a particular processing purpose. We can provide common ready-to-use Analyzers with reasonable defaults that users can look to, i.e. to process a specific language or do another common high-level task with text. Hence, perhaps each Tokenizer can decide what makes the most sense to do based on that particular tokenizer's scope of processing? To Roberts point, this would leave processing totally arbitrary and consistent, but this would be _by design_ as it wouldn't be Tokenizer's role to enforce any overall consistency -- i.e. with regards to punctuation -- higher level Analyzers would provide that. Thoughts? When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole - Key: LUCENE-3940 URL: https://issues.apache.org/jira/browse/LUCENE-3940 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 4.0 Attachments: LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch I modified BaseTokenStreamTestCase to assert that the start/end offsets match for graph (posLen 1) tokens, and this caught a bug in Kuromoji when the decompounding of a compound token has a punctuation token that's dropped. In this case we should leave hole(s) so that the graph is intact, ie, the graph should look the same as if the punctuation tokens were not initially removed, but then a StopFilter had removed them. This also affects tokens that have no compound over them, ie we fail to leave a hole today when we remove the punctuation tokens. I'm not sure this is serious enough to warrant fixing in 3.6 at the last minute... -- 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-3940) When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole
[
https://issues.apache.org/jira/browse/LUCENE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244118#comment-13244118
]
Robert Muir commented on LUCENE-3940:
-
{quote}
Perhaps it's useful to distinguish between analysis for information retrieval
and analysis for information extraction here?
{quote}
Yes, since we are an information retrieval library, then there is no sense in
adding *traps* and *complexity* to our analysis API.
{quote}
I like Michael's and Steven's idea of doing tokenization that doesn't discard
any information.
{quote}
For IR, this is definitely not information... calling it data is a stretch.
{quote}
If there's an established convention that Tokenizer variants discards
punctuation and produces the terms that are meant to be directly searchable, it
sounds like a good idea that we stick to the convention here as well.
{quote}
Thats what the tokenizers do today, they find tokens (In the IR sense). So
yeah, there is an established convention already. Changing
this would be a *monster trap* because suddenly tons of people would be
indexing tons of useless punctuation. I would strongly
oppose such a change.
When Japanese (Kuromoji) tokenizer removes a punctuation token it should
leave a hole
-
Key: LUCENE-3940
URL: https://issues.apache.org/jira/browse/LUCENE-3940
Project: Lucene - Java
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch,
LUCENE-3940.patch
I modified BaseTokenStreamTestCase to assert that the start/end
offsets match for graph (posLen 1) tokens, and this caught a bug in
Kuromoji when the decompounding of a compound token has a punctuation
token that's dropped.
In this case we should leave hole(s) so that the graph is intact, ie,
the graph should look the same as if the punctuation tokens were not
initially removed, but then a StopFilter had removed them.
This also affects tokens that have no compound over them, ie we fail
to leave a hole today when we remove the punctuation tokens.
I'm not sure this is serious enough to warrant fixing in 3.6 at the
last minute...
--
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] (LUCENE-3934) Residual IDF calculation in the pruning package is wrong
[ https://issues.apache.org/jira/browse/LUCENE-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki resolved LUCENE-3934. --- Resolution: Fixed Fix Version/s: 3.6 Committed in rev. 1308298. Residual IDF calculation in the pruning package is wrong Key: LUCENE-3934 URL: https://issues.apache.org/jira/browse/LUCENE-3934 Project: Lucene - Java Issue Type: Bug Affects Versions: 3.5, 3.6 Reporter: Andrzej Bialecki Assignee: Andrzej Bialecki Fix For: 3.6 Attachments: LUCENE-3934.patch As discussed on the mailing list (http://markmail.org/message/cwnyfqmet3wophec) there seems to be a bug in both the formula and in the way RIDF is calculated. The formula is missing a minus, but also the calculation uses local (in-document) term frequency instead of the total term frequency (sum of all term occurrences in a corpus). -- 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-3940) When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole
[
https://issues.apache.org/jira/browse/LUCENE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244124#comment-13244124
]
Robert Muir commented on LUCENE-3940:
-
{quote}
This is certainly useful in the case of information extraction. For example, if
we'd like to extract noun-phrases based on part-of-speech tags, we don't want
to conjoin tokens in case there's a punctuation character between two nouns
(unless that punctuation character is a middle dot).
{quote}
The option still exists in kuromoji (discardPunctuation=false) if you want to
use it for this.
I added this option because it originally kept the punctuation (for downstream
filters to remove).
lucene-gosen worked the same way, and after some time i saw *numerous* examples
across the internet
where people simply configured the tokenizer without any filters, which means
huge amounts of
punctuation being indexed by default. People don't pay attention to
documentation or details,
so all these people were getting bad performance.
Based on this experience, I didn't want keeping punctuation to be the default,
nor even achievable
via things like solr factories here. But i added the (expert) option to
Kuromoji because its really
a more general purpose things for japanese analysis, because its already being
used for other things,
and because allowing a boolean was not expensive or complex to support.
But I don't consider this a bonafied option from the lucene apis, i would be
strongly against adding
this to the solr factories, or as an option to KuromojiAnalyzer. And, I don't
think we should add such
a thing to other tokenizers either.
Our general mission is search, if we want to decide we are expanding our
analysis API to be generally
useful outside of information retrieval, thats a much bigger decision with more
complex tradeoffs that
everyone should vote on (e.g. moving analyzers outside of lucene.apache.org and
everything).
When Japanese (Kuromoji) tokenizer removes a punctuation token it should
leave a hole
-
Key: LUCENE-3940
URL: https://issues.apache.org/jira/browse/LUCENE-3940
Project: Lucene - Java
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch,
LUCENE-3940.patch
I modified BaseTokenStreamTestCase to assert that the start/end
offsets match for graph (posLen 1) tokens, and this caught a bug in
Kuromoji when the decompounding of a compound token has a punctuation
token that's dropped.
In this case we should leave hole(s) so that the graph is intact, ie,
the graph should look the same as if the punctuation tokens were not
initially removed, but then a StopFilter had removed them.
This also affects tokens that have no compound over them, ie we fail
to leave a hole today when we remove the punctuation tokens.
I'm not sure this is serious enough to warrant fixing in 3.6 at the
last minute...
--
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-3930) nuke jars from source tree and use ivy
[
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244137#comment-13244137
]
Robert Muir commented on LUCENE-3930:
-
{quote}
patch fixing the first two problems i mentioned above:
{quote}
Thanks Hossman: I committed this (I am looking at the 3.x merge, i don't want
to find/fix the bug twice)!
nuke jars from source tree and use ivy
--
Key: LUCENE-3930
URL: https://issues.apache.org/jira/browse/LUCENE-3930
Project: Lucene - Java
Issue Type: Task
Components: general/build
Reporter: Robert Muir
Assignee: Robert Muir
Priority: Blocker
Fix For: 3.6
Attachments: LUCENE-3930-skip-sources-javadoc.patch,
LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch,
LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch,
LUCENE-3930__ivy_bootstrap_target.patch,
LUCENE-3930_includetestlibs_excludeexamplexml.patch,
ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch,
patch-jetty-build.patch, pom.xml
As mentioned on the ML thread: switch jars to ivy mechanism?.
--
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-3303) defType param completely ignored
[
https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244139#comment-13244139
]
Erick Erickson commented on SOLR-3303:
--
Could you attach some examples? There's nothing here I can use to reproduce
this. In particular, please attach the results of adding debugQuery=on to the
query that fails along with an explanation of what you think is wrong.
I would be hugely surprised if this were true. I just ran a quick test and it's
behaving as I expect for the query:
http://localhost:8983/solr/select?q=maxtordefType=edismaxfl=name,iddebugQuery=onwt=json
{noformat}
{
responseHeader: {
status: 0,
QTime: 0,
params: {
fl: name,id,
debugQuery: on,
wt: json,
q: maxtor,
defType: edismax
}
},
response: {
numFound: 1,
start: 0,
docs: [
{
name: Maxtor DiamondMax 11 - hard drive - 500 GB - SATA-300
}
]
},
debug: {
rawquerystring: maxtor,
querystring: maxtor,
parsedquery: +DisjunctionMaxQuery((text:maxtor)),
parsedquery_toString: +(text:maxtor),
explain: removed
QParser: ExtendedDismaxQParser,
etc.
{noformat}
defType param completely ignored
Key: SOLR-3303
URL: https://issues.apache.org/jira/browse/SOLR-3303
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Bráulio Bhavamitra
Priority: Critical
I've reproduced this bug using the geodist ordering.
'defType' is being completely ignored, and it don't change nothing with 'qt'
added or not.
I'm supposing that in later case defType must be informed, cause edismax (or
dismax) is not default.
The correct behaviour is expected when not using qt (defaulting to the
default handler with no default defType value specified in solrconfig.xml)
and using defType would make the query work.
--
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-3011) DIH MultiThreaded bug
[ https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244160#comment-13244160 ] James Dyer commented on SOLR-3011: -- If the changes in 3.6 break FileListEntityProcessor then we should try and fix it. A failing unit test would help a lot. As a workaround, you should always be able to use the 3.5 jar with 3.6. 4.0 is only going to support single-threaded DIH configurations. I understand that some users have gotten performance gains using threads and haven't had problems. I suspect these were mostly cases like yours where you're processing text documents and have a somewhat simple configuration. But looking at the code, I don't think we can guarantee DIH using the threads parameter will never encounter a race condition, etc, and that some configurations (especially using SQL, caching, etc) were not working at all (which SOLR-3011 at least mostly fixes). It was also getting hard to add new features because all bets were pretty much off as to whether or not any changes would work with threads. Long term, I would like to see some type of multi-threading added back in. But we do need to refactor the code. I am looking now in trying to consolidate some of the objects that DIH passes around, reducing member visibility, making things immutable, etc. Some of the classes need to be made simpler (DocBuilder comes to mind). Hopefully we can have a code base that can be more easily made threadsafe in the future. DIH MultiThreaded bug - Key: SOLR-3011 URL: https://issues.apache.org/jira/browse/SOLR-3011 Project: Solr Issue Type: Sub-task Components: contrib - DataImportHandler Affects Versions: 3.5 Reporter: Mikhail Khludnev Assignee: James Dyer Priority: Minor Fix For: 3.6 Attachments: SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, SOLR-3011.patch, patch-3011-EntityProcessorBase-iterator.patch, patch-3011-EntityProcessorBase-iterator.patch current DIH design is not thread safe. see last comments at SOLR-2382 and SOLR-2947. I'm going to provide the patch makes DIH core threadsafe. Mostly it's a SOLR-2947 patch from 28th Dec. -- 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 - Build # 12938 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12938/ 1 tests failed. REGRESSION: org.apache.solr.cloud.RecoveryZkTest.testDistribSearch Error Message: Uncaught exception by thread: Thread[Lucene Merge Thread #1,6,] Stack Trace: org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread: Uncaught exception by thread: Thread[Lucene Merge Thread #1,6,] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:84) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) 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.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: org.apache.lucene.index.MergePolicy$MergeException: org.apache.lucene.store.AlreadyClosedException: this Directory is closed at org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:507) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480) Caused by: org.apache.lucene.store.AlreadyClosedException: this Directory is closed at org.apache.lucene.store.Directory.ensureOpen(Directory.java:244) at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:241) at org.apache.lucene.index.IndexFileDeleter.refresh(IndexFileDeleter.java:345) at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3019) at org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382) at org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451) Build Log (for compile errors): [...truncated 9756 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3303) defType param completely ignored
[ https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244178#comment-13244178 ] Bráulio Bhavamitra commented on SOLR-3303: -- please try http://bhakta.casadomato.org:8983/solr/select?wt=rubyfl=pk_s%2Cscorefacet.mincount=1defType=edismaxfacet.sort=countd=200start=0json.nl=arrarrq=%7B%21boost%20b%3Drecip%28geodist%28%29%2C0%2C1%2C1%29%7D%20%28type_s%3A%22Product%22%29rows=100facet.limit=-1spellcheck.collate=trueqt=geofacet.field=f_region_facetfacet.field=f_category_facetfacet.field=f_qualifier_facetspellcheck=truesfield=latlngpt=-22.9035393%2C%20-43.2095869fq=public_b%3Atruefq=%7B%21geofilt%7Dfq=environment_id_i%3A2facet=true and http://bhakta.casadomato.org:8983/solr/select?qt=searchwt=rubyfl=pk_s%2Cscorefacet.mincount=1defType=edismaxfacet.sort=countd=200start=0json.nl=arrarrq=%7B%21boost%20b%3Drecip%28geodist%28%29%2C0%2C1%2C1%29%7D%20%28type_s%3A%22Product%22%29rows=100facet.limit=-1spellcheck.collate=trueqt=geofacet.field=f_region_facetfacet.field=f_category_facetfacet.field=f_qualifier_facetspellcheck=truesfield=latlngpt=-22.9035393%2C%20-43.2095869fq=public_b%3Atruefq=%7B%21geofilt%7Dfq=environment_id_i%3A2facet=true thank you defType param completely ignored Key: SOLR-3303 URL: https://issues.apache.org/jira/browse/SOLR-3303 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Bráulio Bhavamitra Priority: Critical I've reproduced this bug using the geodist ordering. 'defType' is being completely ignored, and it don't change nothing with 'qt' added or not. I'm supposing that in later case defType must be informed, cause edismax (or dismax) is not default. The correct behaviour is expected when not using qt (defaulting to the default handler with no default defType value specified in solrconfig.xml) and using defType would make the query work. -- 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-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-3218: -- Attachment: SOLR-3218.patch Updated patch * Patch is in correct format, starting form project root, not from solr * Fixes indexOutOfRange bug for start=0 * Velocity GUI support * SolrJ support * Now puts plain String's in the NamedList instead of CurrencyValue's - easier to transport around The alternative to using Strings is to move CurrencyValue to solrj package, what do you think? Still needs many more test cases Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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-3303) defType param completely ignored
[
https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244182#comment-13244182
]
Yonik Seeley commented on SOLR-3303:
http://wiki.apache.org/solr/SolrQuerySyntax
In standard Solr search handlers, the defType param can be used to specify the
default type of the main query (ie: the q param) but it only affects the main
query -- The default type of all other query parameters will remain lucene.
You explicitly specified the query type as boost via your use of q={!boost...}
defType param completely ignored
Key: SOLR-3303
URL: https://issues.apache.org/jira/browse/SOLR-3303
Project: Solr
Issue Type: Bug
Affects Versions: 3.5
Reporter: Bráulio Bhavamitra
Priority: Critical
I've reproduced this bug using the geodist ordering.
'defType' is being completely ignored, and it don't change nothing with 'qt'
added or not.
I'm supposing that in later case defType must be informed, cause edismax (or
dismax) is not default.
The correct behaviour is expected when not using qt (defaulting to the
default handler with no default defType value specified in solrconfig.xml)
and using defType would make the query work.
--
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-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244188#comment-13244188 ] Yonik Seeley commented on SOLR-3218: bq. The alternative to using Strings is to move CurrencyValue to solrj package, what do you think? Strings are good since it doesn't seem like we should push dependencies like this into solrj. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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-3307) DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011
DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011 -- Key: SOLR-3307 URL: https://issues.apache.org/jira/browse/SOLR-3307 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6 Reporter: Bernd Fehling Assignee: James Dyer Fix For: 3.6 As reported in issue SOLR-3011 the FileListEntityProcessor is not recursing through all sub-directories and files after applying SOLR-3011.patch. -- 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-3307) DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011
[ https://issues.apache.org/jira/browse/SOLR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Fehling updated SOLR-3307: Attachment: SOLR-3307-UnitTest.patch Unit test patch TestMultiThreadedFileReader. DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011 -- Key: SOLR-3307 URL: https://issues.apache.org/jira/browse/SOLR-3307 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6 Reporter: Bernd Fehling Assignee: James Dyer Fix For: 3.6 Attachments: SOLR-3307-UnitTest.patch As reported in issue SOLR-3011 the FileListEntityProcessor is not recursing through all sub-directories and files after applying SOLR-3011.patch. -- 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-3307) DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011
[ https://issues.apache.org/jira/browse/SOLR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244227#comment-13244227 ] Bernd Fehling edited comment on SOLR-3307 at 4/2/12 2:36 PM: - Unit test patch TestMultiThreadedFileReader added. was (Author: befehl): Unit test patch TestMultiThreadedFileReader. DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011 -- Key: SOLR-3307 URL: https://issues.apache.org/jira/browse/SOLR-3307 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6 Reporter: Bernd Fehling Assignee: James Dyer Fix For: 3.6 Attachments: SOLR-3307-UnitTest.patch As reported in issue SOLR-3011 the FileListEntityProcessor is not recursing through all sub-directories and files after applying SOLR-3011.patch. -- 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-3307) DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011
[ https://issues.apache.org/jira/browse/SOLR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244232#comment-13244232 ] Bernd Fehling commented on SOLR-3307: - As far as I could figure out the differences between 3.5 and 3.6 with SOLR-3011 are: * with 3.5 ** I get a single FileListEntityProcessor with multi-threaded XPathEntityProcessor (according to number of threads) ** threads parameter effects rootEntity * with 3.6 and SOLR-3011 ** I get multi-threaded FileListEntityProcessor (according to number of threads) with multi-threaded XPathEntityProcessor ** threads parameter effects also all entities above rootEntity DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011 -- Key: SOLR-3307 URL: https://issues.apache.org/jira/browse/SOLR-3307 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6 Reporter: Bernd Fehling Assignee: James Dyer Fix For: 3.6 Attachments: SOLR-3307-UnitTest.patch As reported in issue SOLR-3011 the FileListEntityProcessor is not recursing through all sub-directories and files after applying SOLR-3011.patch. -- 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-3303) defType param completely ignored
[ https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-3303. -- Resolution: Invalid I think Yonik answered the question. In the future, please bring this type of question up on the user's list before raising a JIRA, just to check whether it's a code or usage problem. defType param completely ignored Key: SOLR-3303 URL: https://issues.apache.org/jira/browse/SOLR-3303 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Bráulio Bhavamitra Priority: Critical I've reproduced this bug using the geodist ordering. 'defType' is being completely ignored, and it don't change nothing with 'qt' added or not. I'm supposing that in later case defType must be informed, cause edismax (or dismax) is not default. The correct behaviour is expected when not using qt (defaulting to the default handler with no default defType value specified in solrconfig.xml) and using defType would make the query work. -- 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-3303) defType param completely ignored
[ https://issues.apache.org/jira/browse/SOLR-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244239#comment-13244239 ] Bráulio Bhavamitra commented on SOLR-3303: -- thank you yonik. but shouldn't qt=search be used as the default as specified at solrconfig.xml? it seems strange to be needed and the have the default=true. defType param completely ignored Key: SOLR-3303 URL: https://issues.apache.org/jira/browse/SOLR-3303 Project: Solr Issue Type: Bug Affects Versions: 3.5 Reporter: Bráulio Bhavamitra Priority: Critical I've reproduced this bug using the geodist ordering. 'defType' is being completely ignored, and it don't change nothing with 'qt' added or not. I'm supposing that in later case defType must be informed, cause edismax (or dismax) is not default. The correct behaviour is expected when not using qt (defaulting to the default handler with no default defType value specified in solrconfig.xml) and using defType would make the query work. -- 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] (LUCENE-3932) Improve load time of .tii files
[
https://issues.apache.org/jira/browse/LUCENE-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244290#comment-13244290
]
Sean Bridges edited comment on LUCENE-3932 at 4/2/12 4:16 PM:
--
{quote}I'm curious how much larger it'd be if we stopped delta coding... for
your case, how large is the byte[] in RAM (just call
dataPagedBytes.getPointer(), just before we freeze it, and print that result)
vs the tii on disk...?{quote}
dataPagedBytes.getPointer() == 124973970
On disk the .tii file is 69508193 bytes
The entire index is ~50 gigs.
was (Author: sgbridges):
{quote}I'm curious how much larger it'd be if we stopped delta coding...
for your case, how large is the byte[] in RAM (just call
dataPagedBytes.getPointer(), just before we freeze it, and print that result)
vs the tii on disk...?{quote}
dataPagedBytes.getPointer() == 124973970
On disk the .tii file is 69508193 bytes
Improve load time of .tii files
---
Key: LUCENE-3932
URL: https://issues.apache.org/jira/browse/LUCENE-3932
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5
Environment: Linux
Reporter: Sean Bridges
Attachments: LUCENE-3932.trunk.patch, perf.csv
We have a large 50 gig index which is optimized as one segment, with a 66 MEG
.tii file. This index has no norms, and no field cache.
It takes about 5 seconds to load this index, profiling reveals that 60% of
the time is spent in GrowableWriter.set(index, value), and most of time in
set(...) is spent resizing PackedInts.Mutatable current.
In the constructor for TermInfosReaderIndex, you initialize the writer with
the line,
{quote}GrowableWriter indexToTerms = new GrowableWriter(4, indexSize,
false);{quote}
For our index using four as the bit estimate results in 27 resizes.
The last value in indexToTerms is going to be ~ tiiFileLength, and if instead
you use,
{quote}int bitEstimate = (int) Math.ceil(Math.log10(tiiFileLength) /
Math.log10(2));
GrowableWriter indexToTerms = new GrowableWriter(bitEstimate, indexSize,
false);{quote}
Load time improves to ~ 2 seconds.
--
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-3932) Improve load time of .tii files
[
https://issues.apache.org/jira/browse/LUCENE-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244290#comment-13244290
]
Sean Bridges commented on LUCENE-3932:
--
{quote}I'm curious how much larger it'd be if we stopped delta coding... for
your case, how large is the byte[] in RAM (just call
dataPagedBytes.getPointer(), just before we freeze it, and print that result)
vs the tii on disk...?{quote}
dataPagedBytes.getPointer() == 124973970
On disk the .tii file is 69508193 bytes
Improve load time of .tii files
---
Key: LUCENE-3932
URL: https://issues.apache.org/jira/browse/LUCENE-3932
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 3.5
Environment: Linux
Reporter: Sean Bridges
Attachments: LUCENE-3932.trunk.patch, perf.csv
We have a large 50 gig index which is optimized as one segment, with a 66 MEG
.tii file. This index has no norms, and no field cache.
It takes about 5 seconds to load this index, profiling reveals that 60% of
the time is spent in GrowableWriter.set(index, value), and most of time in
set(...) is spent resizing PackedInts.Mutatable current.
In the constructor for TermInfosReaderIndex, you initialize the writer with
the line,
{quote}GrowableWriter indexToTerms = new GrowableWriter(4, indexSize,
false);{quote}
For our index using four as the bit estimate results in 27 resizes.
The last value in indexToTerms is going to be ~ tiiFileLength, and if instead
you use,
{quote}int bitEstimate = (int) Math.ceil(Math.log10(tiiFileLength) /
Math.log10(2));
GrowableWriter indexToTerms = new GrowableWriter(bitEstimate, indexSize,
false);{quote}
Load time improves to ~ 2 seconds.
--
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
carrot2 clustering in trunk uses OLDER jackson than 3.x?
while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3873) tie MockGraphTokenFilter into all analyzers tests
[ https://issues.apache.org/jira/browse/LUCENE-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3873: --- Attachment: LUCENE-3873.patch New patch, fixing all nocommits. I think it's ready... tie MockGraphTokenFilter into all analyzers tests - Key: LUCENE-3873 URL: https://issues.apache.org/jira/browse/LUCENE-3873 Project: Lucene - Java Issue Type: Task Components: modules/analysis Reporter: Robert Muir Assignee: Michael McCandless Attachments: LUCENE-3873.patch, LUCENE-3873.patch Mike made a MockGraphTokenFilter on LUCENE-3848. Many filters currently arent tested with anything but a simple tokenstream. we should test them with this, too, it might find bugs (zero-length terms, stacked terms/synonyms, etc) -- 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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
I think this is because the Carrot2 update to version 3.5.0.1 ( https://issues.apache.org/jira/browse/SOLR-3294) went only to the 3.x branch, leaving trunk with the slightly older 3.5.0 version. There shouldn't be any problems with applying the same update on trunk I think. This would bring all the dependencies in sync. S. On Mon, Apr 2, 2012 at 18:36, Robert Muir rcm...@gmail.com wrote: while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3941) Maven Build Broken - Bootstrap fails
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: Realtime Branch
Reporter: Tobias Rübner
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because the contributed libs are missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{code}
I think this has something to do with the switch to ivy. - [#LUCENE-3930]
--
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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
Hi Robert, Indeed, I upgraded these. This is actually the version used in 3.5.0 -- http://search.maven.org/remotecontent?filepath=org/carrot2/carrot2/3.5.0/carrot2-3.5.0.pom So the JARs in Solr were kind of older. Dawid On Mon, Apr 2, 2012 at 6:36 PM, Robert Muir rcm...@gmail.com wrote: while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: carrot2 clustering in trunk uses OLDER jackson than 3.x?
On Mon, Apr 2, 2012 at 12:49 PM, Stanislaw Osinski stanis...@osinski.name wrote: I think this is because the Carrot2 update to version 3.5.0.1 (https://issues.apache.org/jira/browse/SOLR-3294) went only to the 3.x branch, leaving trunk with the slightly older 3.5.0 version. There shouldn't be any problems with applying the same update on trunk I think. This would bring all the dependencies in sync. I think that you should 'shade' (package rename) carrot to hide the Jackson dependences. S. On Mon, Apr 2, 2012 at 18:36, Robert Muir rcm...@gmail.com wrote: while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- 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
[jira] [Commented] (LUCENE-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244331#comment-13244331
]
Tobias Rübner commented on LUCENE-3941:
---
The file name has changed.
It now has a git revision number:
langdetect-c51112119be53a81e59706ce57bacaa90c052284.jar
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: Realtime Branch
Reporter: Tobias Rübner
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because the contributed libs are missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{code}
I think this has something to do with the switch to ivy. - [#LUCENE-3930]
--
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-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Rübner updated LUCENE-3941:
--
Description:
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because a contributed lib is missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{code}
was:
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because the contributed libs are missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{code}
I think this has something to do with the switch to ivy. - [#LUCENE-3930]
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: Realtime Branch
Reporter: Tobias Rübner
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because a contributed lib is missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{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
Re: carrot2 clustering in trunk uses OLDER jackson than 3.x?
I'm afraid I'll have to say no to this. Carrot2 depends on many external libraries (much like Solr). You have the freedom (or not) of shading or obfuscating or repackaging. Even overriding with an explicit version of a given library as much as it's API compatible with what the POM declares. Repackaging is fun but it's not a cure for all the problems. Dawid On Mon, Apr 2, 2012 at 6:55 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Apr 2, 2012 at 12:49 PM, Stanislaw Osinski stanis...@osinski.name wrote: I think this is because the Carrot2 update to version 3.5.0.1 (https://issues.apache.org/jira/browse/SOLR-3294) went only to the 3.x branch, leaving trunk with the slightly older 3.5.0 version. There shouldn't be any problems with applying the same update on trunk I think. This would bring all the dependencies in sync. I think that you should 'shade' (package rename) carrot to hide the Jackson dependences. S. On Mon, Apr 2, 2012 at 18:36, Robert Muir rcm...@gmail.com wrote: while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- 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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
On Mon, Apr 2, 2012 at 12:59 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: I'm afraid I'll have to say no to this. Carrot2 depends on many external libraries (much like Solr). You have the freedom (or not) of shading or obfuscating or repackaging. Even overriding with an explicit version of a given library as much as it's API compatible with what the POM declares. Dawid, I don't think that you (carrot as a library) should do any shading. I think that when someone prepares a Solr component including carrot, that they should avoid dependencies that possibly conflict. Jackson is a particular risk factor, since 'minor' versions are mutually incompatible, so the presence of Jackson x.y precludes the use of some other package that requires jackson x.z. -benson Repackaging is fun but it's not a cure for all the problems. Dawid On Mon, Apr 2, 2012 at 6:55 PM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Apr 2, 2012 at 12:49 PM, Stanislaw Osinski stanis...@osinski.name wrote: I think this is because the Carrot2 update to version 3.5.0.1 (https://issues.apache.org/jira/browse/SOLR-3294) went only to the 3.x branch, leaving trunk with the slightly older 3.5.0 version. There shouldn't be any problems with applying the same update on trunk I think. This would bring all the dependencies in sync. I think that you should 'shade' (package rename) carrot to hide the Jackson dependences. S. On Mon, Apr 2, 2012 at 18:36, Robert Muir rcm...@gmail.com wrote: while reviewing dependencies, this looked funky: trunk: jackson-core-asl: 1.5.2 jackson-mapper-asl: 1.5.2 3.x: jackson-core-asl: 1.7.4 jackson-mapper-asl: 1.7.4 Is this a mistake? or does jackson release numbers backwards? or is it intentional? if so I'd like to just add a comment... -- 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244342#comment-13244342 ] Robert Muir commented on LUCENE-3930: - I merged back to branch_3x. will let hudson chomp on it for a while, then mark this issue resolved if there are no immediate problems. Any later improvements can be followup issues. nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, LUCENE-3930_includetestlibs_excludeexamplexml.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch, pom.xml As mentioned on the ML thread: switch jars to ivy mechanism?. -- 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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
I don't think that you (carrot as a library) should do any shading. I think that when someone prepares a Solr component including carrot, that they should avoid dependencies that possibly conflict. Jackson is a particular risk factor, since 'minor' versions are mutually incompatible, so the presence of Jackson x.y precludes the use of some other package that requires jackson x.z. I realize this but then I think shading should be used exactly when somebody encounters this kind of problem (incompatible versions must coexist on classpath). It is a pain. It is wrong. But it's a less error-prone solution than shading everything possible for every possible package out there. I don't rule out the possibility that we will be preparing a self-contained release in the future because JAR conflicts are a common issue, but I also kind of know for a fact what kind of pain it is because we _are_ trimming the distribution for .net cross-compilation (which in the essence is similar to package renaming/ obfuscation). It is an unbelievably tedious process to check if everything works after each upgrade (even with tests and everything). Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2435) Duplicate Jars in release packages
[ https://issues.apache.org/jira/browse/SOLR-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2435: -- Attachment: SOLR-2435_duplicate_junit.patch patch for the duplicate junit: its worthless and confusing, and trivial to fix (just nuke it). Duplicate Jars in release packages -- Key: SOLR-2435 URL: https://issues.apache.org/jira/browse/SOLR-2435 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 4.0 Attachments: SOLR-2435_duplicate_junit.patch Reviewing the 3.1 release candidates, i've noticed that in a few places we have duplicated jars. of particular note is the ICU4J jar, which not only exists in two different solr contrib lib directories, but also exists in modules. -- 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-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244384#comment-13244384
]
Steven Rowe commented on LUCENE-3941:
-
Hi Tobias,
Thanks for reporting.
I'm working on it. Should be functional later today.
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: Realtime Branch
Reporter: Tobias Rübner
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because a contributed lib is missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{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] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244399#comment-13244399 ] Robert Muir commented on LUCENE-3738: - Uwe, is this one good to go now? Can we mark it resolved? Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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-1052) Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244401#comment-13244401 ] Robert Muir commented on SOLR-1052: --- Jan: looks like you are just waiting for feedback for the port-forward to trunk here? Nothing remains for 3.x? Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x-fix-tests.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate old indexDefaults and mainIndex sections and only use a new indexConfig section. 3.6: Deprecation warning if old section used 4.0: If LuceneMatchVersion before LUCENE_40 then warn (so old configs will work), else fail fast -- 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-3.x-java7 - Build # 2167 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/2167/ All tests passed Build Log (for compile errors): [...truncated 26485 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3218) Range faceting support for CurrencyField
[ https://issues.apache.org/jira/browse/SOLR-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244409#comment-13244409 ] Jan Høydahl commented on SOLR-3218: --- The conversion to String from CurrencyValue is a bit of a hack with instanceof tests, since I was not allowed to return String from getValue in CurrencyValue. Not very object oriented.. Range faceting support for CurrencyField Key: SOLR-3218 URL: https://issues.apache.org/jira/browse/SOLR-3218 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Fix For: 4.0 Attachments: SOLR-3218-1.patch, SOLR-3218-2.patch, SOLR-3218.patch, SOLR-3218.patch, SOLR-3218.patch Spinoff from SOLR-2202. Need to add range faceting capabilities for CurrencyField -- 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-Solr-tests-only-3.x-java7 - Build # 2167 - Failure
Hasn't yet picked up my svn:ignores in r1308443... next run should catch it. Because of this it thought the checkout was dirty after running tests. On Mon, Apr 2, 2012 at 2:25 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/2167/ All tests passed Build Log (for compile errors): [...truncated 26485 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved LUCENE-3941.
-
Resolution: Fixed
Fix Version/s: 4.0
Assignee: Steven Rowe
Committed fixes in r1308456. The Maven build works now.
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: Realtime Branch
Reporter: Tobias Rübner
Assignee: Steven Rowe
Fix For: 4.0
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because a contributed lib is missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{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] [Updated] (LUCENE-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3941:
Affects Version/s: (was: Realtime Branch)
4.0
Maven Build Broken - Bootstrap fails
Key: LUCENE-3941
URL: https://issues.apache.org/jira/browse/LUCENE-3941
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: 4.0
Reporter: Tobias Rübner
Assignee: Steven Rowe
Fix For: 4.0
Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
because a contributed lib is missing.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
(install-langdetect) on project lucene-solr-grandparent:
Error installing artifact 'org.apache.solr:solr-langdetect:jar':
Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
/home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
(No such file or directory) - [Help 1]
{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] [Created] (LUCENE-3942) SynonymFilter should set pos length att
SynonymFilter should set pos length att --- Key: LUCENE-3942 URL: https://issues.apache.org/jira/browse/LUCENE-3942 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.0 Tokenizers/Filters can now produce graphs instead of a single linear chain of tokens, by setting the PositionLengthAttribute, expressing where (how many positions ahead) this token ends. The default is 1, meaning it ends at the next position, to be backwards compatible. SynonymFilter produces graph output tokens, as long as the output is a single token, but currently never sets the pos length to express this. EG for the rule wifi network - hotspot, the hotspot token should have pos length = 2. With LUCENE-3940 this will allow us to verify that the offsets for such tokens are correct... -- 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-3942) SynonymFilter should set pos length att
[ https://issues.apache.org/jira/browse/LUCENE-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3942: --- Attachment: LUCENE-3942.patch Patch to set pos length 1 when appropriate... I think it's ready. Note that SynFilter still cannot *consume* a graph, so eg you cannot apply it after WDF or after Kuromoji... we need to separately fix that. SynonymFilter should set pos length att --- Key: LUCENE-3942 URL: https://issues.apache.org/jira/browse/LUCENE-3942 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.0 Attachments: LUCENE-3942.patch Tokenizers/Filters can now produce graphs instead of a single linear chain of tokens, by setting the PositionLengthAttribute, expressing where (how many positions ahead) this token ends. The default is 1, meaning it ends at the next position, to be backwards compatible. SynonymFilter produces graph output tokens, as long as the output is a single token, but currently never sets the pos length to express this. EG for the rule wifi network - hotspot, the hotspot token should have pos length = 2. With LUCENE-3940 this will allow us to verify that the offsets for such tokens are correct... -- 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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
On Mon, Apr 2, 2012 at 1:12 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: I don't think that you (carrot as a library) should do any shading. I think that when someone prepares a Solr component including carrot, that they should avoid dependencies that possibly conflict. Jackson is a particular risk factor, since 'minor' versions are mutually incompatible, so the presence of Jackson x.y precludes the use of some other package that requires jackson x.z. I realize this but then I think shading should be used exactly when somebody encounters this kind of problem (incompatible versions must coexist on classpath). It is a pain. It is wrong. But it's a less error-prone solution than shading everything possible for every possible package out there. I don't rule out the possibility that we will be preparing a self-contained release in the future because JAR conflicts are a common issue, but I also kind of know for a fact what kind of pain it is because we _are_ trimming the distribution for .net cross-compilation (which in the essence is similar to package renaming/ obfuscation). It is an unbelievably tedious process to check if everything works after each upgrade (even with tests and everything). Of course, some would say that Solr should be based on OSGi just to avoid this sort of conflict. (ducks under desk) Dawid - 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-3304) Implement Solr spatial contrib module with LSP Lucene module
[ https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244490#comment-13244490 ] David Smiley commented on SOLR-3304: We're going to get to it; don't worry Bill. Implement Solr spatial contrib module with LSP Lucene module Key: SOLR-3304 URL: https://issues.apache.org/jira/browse/SOLR-3304 Project: Solr Issue Type: Bug Affects Versions: 4.0 Reporter: Bill Bell Placeholder. The Solr 4 glue. Get the Solr spatial module integrated with the lucene LSP module. -- 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-3304) Add Solr support for the new Lucene spatial module
[ https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-3304: --- Description: Get the Solr spatial module integrated with the lucene spatial module. was: Placeholder. The Solr 4 glue. Get the Solr spatial module integrated with the lucene LSP module. Assignee: David Smiley Labels: spatial (was: ) Issue Type: New Feature (was: Bug) Summary: Add Solr support for the new Lucene spatial module (was: Implement Solr spatial contrib module with LSP Lucene module) Add Solr support for the new Lucene spatial module -- Key: SOLR-3304 URL: https://issues.apache.org/jira/browse/SOLR-3304 Project: Solr Issue Type: New Feature Affects Versions: 4.0 Reporter: Bill Bell Assignee: David Smiley Labels: spatial Get the Solr spatial module integrated with the lucene spatial module. -- 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-3226) SignatureUpdateProcessor ignores non-string field values from the signature generation
[ https://issues.apache.org/jira/browse/SOLR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3226: --- Attachment: SOLR-3226.patch Hmmm just noticed this jira ... this definitely seems like a really bad bug. Spyros: thank you so much for your patch (including tests!) ... i've updated it to also fix the case of Collections that contain non string. SignatureUpdateProcessor ignores non-string field values from the signature generation -- Key: SOLR-3226 URL: https://issues.apache.org/jira/browse/SOLR-3226 Project: Solr Issue Type: Bug Components: update Affects Versions: 3.5, 4.0 Reporter: Spyros Kapnissis Attachments: SOLR-3226.patch, SOLR-3226.patch When using for example XMLUpdateRequestProcessor, the signature is calculated correctly since all field values are strings. But when one uses DataImportHandler or BinaryUpdateRequestHandler, the signature generation will ignore any field values that are ints, longs, dates etc. This might result in overwriting non-similar documents, as it happened in my case while importing some db data through DIH. -- 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-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244502#comment-13244502 ] Michael McCandless commented on SOLR-3296: -- bq. wrt commons-csv alternatives, it's too risky for little/no gain. This confuses me: commons-csv is unreleased, while there are other license-friendly packages (eg opencsv) that have been released for some time (multiple releases), been tested in the field, had bugs found fixed, etc. Why use an unreleased package when released alternatives are available? bq. I put a lot of effort into getting commons-csv up to snuff, Wait: a lot of effort doing what? Did you have to modify commons-csv sources? Or do you mean open issues w/ the commons devs to fix things/add test cases to commons-csv sources (great!)...? bq. Switching implementations would most likely result in a lot of regressions that we don't have tests for. I'd expect the reverse, ie, it's more likely there are bugs in commons-csv (it's not released and thus not heavily tested) than eg in opencsv. And if somehow that's really the case (eg we have particular/unusual CSV parsing requirements), we should have our own tests asserting so? Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- 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-3226) SignatureUpdateProcessor ignores non-string field values from the signature generation
[
https://issues.apache.org/jira/browse/SOLR-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3226:
---
Affects Version/s: 1.4
3.1
3.2
3.3
3.4
Fix Version/s: 3.6
Assignee: Hoss Man
I wanna commit this into 3.6 ... but i'd like to get mark miller to sanity
check th patch first (the instanceof String seems so deliberate i'm not sure if
i'm missing something - i've pinged him on IRC to see if he can review ASAP)
Suggested special text for the upgrading section in CHANGES.txt...
{noformat}
A bug found and fixed in the SignatureUpdateProcessor that previously caused
some
documents to produce the same signature even when the configured fields
contained
distinct (non-String) values. Users of SignatureUpdateProcessor are strongly
advised
that they should re-index as document signatures may have now changed.
(see SOLR-3226 for details)
{noformat}
SignatureUpdateProcessor ignores non-string field values from the signature
generation
--
Key: SOLR-3226
URL: https://issues.apache.org/jira/browse/SOLR-3226
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0
Reporter: Spyros Kapnissis
Assignee: Hoss Man
Fix For: 3.6
Attachments: SOLR-3226.patch, SOLR-3226.patch
When using for example XMLUpdateRequestProcessor, the signature is calculated
correctly since all field values are strings. But when one uses
DataImportHandler or BinaryUpdateRequestHandler, the signature generation
will ignore any field values that are ints, longs, dates etc.
This might result in overwriting non-similar documents, as it happened in my
case while importing some db data through DIH.
--
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: carrot2 clustering in trunk uses OLDER jackson than 3.x?
Of course, some would say that Solr should be based on OSGi just to avoid this sort of conflict. (ducks under desk) I _knew_ you'd say this :) D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3200) When using SignatureUpdateProcessor with all fields configuration, it will assume only the fields present on the very first document only, ignoring any optional fields i
[ https://issues.apache.org/jira/browse/SOLR-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3200: --- Affects Version/s: 1.4 3.1 3.2 3.3 3.4 Fix Version/s: 3.6 Assignee: Hoss Man Grr... another one that looks really bad. Patch and tests look good to me (but still doing more testing) so I think we should commit for 3.6 (Same upgrade instructions as SOLR-3226 would cover this) When using SignatureUpdateProcessor with all fields configuration, it will assume only the fields present on the very first document only, ignoring any optional fields in subsequent documents in the signature generation. -- Key: SOLR-3200 URL: https://issues.apache.org/jira/browse/SOLR-3200 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0 Reporter: Spyros Kapnissis Assignee: Hoss Man Fix For: 3.6 Attachments: SOLR-3200.patch This can result in non-duplicate documents being left out of the index. A solution would be that the fields to be used in the signature generation are recalculated with every document inserted. -- 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-2435) Duplicate Jars in release packages
[ https://issues.apache.org/jira/browse/SOLR-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2435: -- Attachment: SOLR-2435_duplicate_junit.patch updated patch: with test-framework ref'ing test.classpath in its javadoc.classpath so that test-framework javadocs work. this is ready for trunk. Duplicate Jars in release packages -- Key: SOLR-2435 URL: https://issues.apache.org/jira/browse/SOLR-2435 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 4.0 Attachments: SOLR-2435_duplicate_junit.patch, SOLR-2435_duplicate_junit.patch Reviewing the 3.1 release candidates, i've noticed that in a few places we have duplicated jars. of particular note is the ICU4J jar, which not only exists in two different solr contrib lib directories, but also exists in modules. -- 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-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244532#comment-13244532 ] Yonik Seeley commented on SOLR-3296: bq. Wait: a lot of effort doing what? http://commons.apache.org/csv/team-list.html I became a CSV committer to address all of the issues. Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- 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-2435) Duplicate Jars in release packages
[
https://issues.apache.org/jira/browse/SOLR-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244538#comment-13244538
]
Robert Muir commented on SOLR-2435:
---
{quote}
in the ICU4J case, at a minimum we can promote the jar up out of the individual
contirbs and into the main lib dir ... but since it's also in modules, it
should be possible to have it copied into the lucene-libs dir (although i'm not
totally up to speed on what builds that dir right now)
{quote}
Seeing as now this issue only affects the _binary release_ and no longer the
source one :)
I think its much less of an issue. I'm not sure how it helps to have icu4j in
lucene-libs versus coming into lib/.
I definitely don't think its a blocker (as we said before, especially now that
it doesnt affect source release),
but its nice to clean up: the junit one is especially confusing, so I'm
committing that one to trunk.
Duplicate Jars in release packages
--
Key: SOLR-2435
URL: https://issues.apache.org/jira/browse/SOLR-2435
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Fix For: 4.0
Attachments: SOLR-2435_duplicate_junit.patch,
SOLR-2435_duplicate_junit.patch
Reviewing the 3.1 release candidates, i've noticed that in a few places we
have duplicated jars.
of particular note is the ICU4J jar, which not only exists in two different
solr contrib lib directories, but also exists in modules.
--
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-3296) Explore alternatives to Commons CSV
[ https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-3296: -- Attachment: SOLR-3296_noggit.patch patch for noggit: nuking the local copy of noggit (--no-diff-deleted), and using the download instead (changing package names to org.noggit where its used). all tests and javadocs pass. Explore alternatives to Commons CSV --- Key: SOLR-3296 URL: https://issues.apache.org/jira/browse/SOLR-3296 Project: Solr Issue Type: Improvement Components: Build Reporter: Chris Male Attachments: SOLR-3296_noggit.patch In LUCENE-3930 we're implementing some less than ideal solutions to make available the unreleased version of commons-csv. We could remove these solutions if we didn't rely on this lib. So I think we should explore alternatives. I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to consider, I've used it in many commercial projects. Bizarrely Commons-CSV's website says that Opencsv uses a BSD license, but this isn't the case, OpenCSV uses ASL2. -- 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] (LUCENE-3930) nuke jars from source tree and use ivy
[ https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3930. - Resolution: Fixed Fix Version/s: 4.0 Thanks everyone! nuke jars from source tree and use ivy -- Key: LUCENE-3930 URL: https://issues.apache.org/jira/browse/LUCENE-3930 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir Assignee: Robert Muir Priority: Blocker Fix For: 3.6, 4.0 Attachments: LUCENE-3930-skip-sources-javadoc.patch, LUCENE-3930-solr-example.patch, LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930.patch, LUCENE-3930__ivy_bootstrap_target.patch, LUCENE-3930_includetestlibs_excludeexamplexml.patch, ant_-verbose_clean_test.out.txt, noggit-commons-csv.patch, patch-jetty-build.patch, pom.xml As mentioned on the ML thread: switch jars to ivy mechanism?. -- 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: Failing lucene-core tests in oal.junitcompat package under IntelliJ
Hi Dawid, On 4/2/2012 at 4:25 PM, Dawid Weiss wrote: These are nested tests that test the tests... Hope you like the tongue twister ;) I figured it was something like that. Anyway, these test suites shouldn't be executed as stand-alone classes because they are intentional failures that are asserted someplace else (in the outer class typically). Is there a way to tell Idea to just run *Test and Test* classes? AFAICT, it's possible to either: a) run all tests in a module (it's set up to do this now); or b) run tests whose names match pattern(s). (AFAICT this one is a brand new feature in IntelliJ v11.1: http://youtrack.jetbrains.com/issue/IDEA-78962) But not both at once. So I'm not sure how to run Test*;*Test under the IntelliJ lucene module, which includes test source roots lucene/core/src/test/ and lucene/test-framework/src/java/. I can work around some of these using assumptions but not right now (I don't even have IntelliJ Idea) -- file an issue if there's no other way and I'll see what I can do. No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. Thanks, Steve
Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ
No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. I'll look into it. I remember I did some of the assume-running-nested already for Eclipse so it should be there anyway, maybe I missed something. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Failing lucene-core tests in oal.junitcompat package under IntelliJ
I asked on the JetBrains issue about running tests matching patterns drawn from a single module: http://youtrack.jetbrains.com/issue/IDEA-78962#comment=27-315476 -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 5:15 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. I'll look into it. I remember I did some of the assume-running-nested already for Eclipse so it should be there anyway, maybe I missed something. Dawid - 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 # 12942 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12942/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch Error Message: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:819) at org.apache.lucene.util.LuceneTestCase.access$900(LuceneTestCase.java:138) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:676) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) 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.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch: Insane FieldCache usage(s) found expected:0 but was:1 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:930) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:809) ... 28 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=93 closes=91 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=93 closes=91 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974) at junit.framework.TestResult.addError(TestResult.java:38) at junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51) at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41) at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97) at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26) at org.junit.runners.ParentRunner.run(ParentRunner.java:306) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911)
[jira] [Commented] (SOLR-3296) Explore alternatives to Commons CSV
[
https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244683#comment-13244683
]
Jan Høydahl commented on SOLR-3296:
---
{quote}
http://commons.apache.org/csv/team-list.html
I became a CSV committer to address all of the issues.
{quote}
Great Yonik. As a CSV committer, could you not initiate a release? On the csv
web site, it says:
bq. There are currently no official downloads, and will not be until CSV moves
out of the Sandbox
CSV has moved out of the Sandbox, so what stops you (the team) from taking the
code as is and releasing it, perhaps as a 0.x version?
Explore alternatives to Commons CSV
---
Key: SOLR-3296
URL: https://issues.apache.org/jira/browse/SOLR-3296
Project: Solr
Issue Type: Improvement
Components: Build
Reporter: Chris Male
Attachments: SOLR-3296_noggit.patch
In LUCENE-3930 we're implementing some less than ideal solutions to make
available the unreleased version of commons-csv. We could remove these
solutions if we didn't rely on this lib. So I think we should explore
alternatives.
I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to
consider, I've used it in many commercial projects. Bizarrely Commons-CSV's
website says that Opencsv uses a BSD license, but this isn't the case,
OpenCSV uses ASL2.
--
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-3295) Binaries contain 1.6 classes
[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244694#comment-13244694
]
Robert Muir commented on SOLR-3295:
---
Is it possible for anyone to write a solr-level test? I tried to make one
(using testrh.nc from
http://www.unidata.ucar.edu/software/netcdf/examples/files.html)
{noformat}
Index:
solr/contrib/extraction/src/test/org/apache/solr/handler/extraction/ExtractingRequestHandlerTest.java
===
---
solr/contrib/extraction/src/test/org/apache/solr/handler/extraction/ExtractingRequestHandlerTest.java
(revision 1308448)
+++
solr/contrib/extraction/src/test/org/apache/solr/handler/extraction/ExtractingRequestHandlerTest.java
(working copy)
@@ -445,6 +445,17 @@
catch(Exception expected){}
}
+ public void testCDF() throws Exception {
+ExtractingRequestHandler handler = (ExtractingRequestHandler)
h.getCore().getRequestHandler(/update/extract);
+assertTrue(handler is null and it shouldn't be, handler != null);
+loadLocal(extraction/testrh.nc,
+literal.id, one,
+fmap.content, extractedContent
+);
+assertU(commit());
+assertQ(req(*:*), //result[@numFound=1]);
+ }
+
SolrQueryResponse loadLocal(String filename, String... args) throws
Exception {
LocalSolrQueryRequest req = (LocalSolrQueryRequest) req(args);
try {
{noformat}
But on my java5 jdk, this test passes. I guess i dont know enough about whats
going on with contrib/extraction
here to figure this out. But i saw options like 'ignore exceptions from tika'
and it seems like there are a lot
of options.
I'd like to get a 3.6 release candidate out soon...
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 3.6
Attachments: output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
platform: 45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{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
[jira] [Commented] (LUCENE-2026) Refactoring of IndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244701#comment-13244701 ] Tim A. commented on LUCENE-2026: - Hi, I am a Computer Science student from Germany. I would like to contribute to this project under GSoC 2012. I have very good experience in Java. I have some questions to this project, can someone help me? IRC or instant messanger? Thank You Tim Refactoring of IndexWriter -- Key: LUCENE-2026 URL: https://issues.apache.org/jira/browse/LUCENE-2026 Project: Lucene - Java Issue Type: Improvement Components: core/index Reporter: Michael Busch Assignee: Michael Busch Priority: Minor Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, mentor Fix For: 4.0 I've been thinking for a while about refactoring the IndexWriter into two main components. One could be called a SegmentWriter and as the name says its job would be to write one particular index segment. The default one just as today will provide methods to add documents and flushes when its buffer is full. Other SegmentWriter implementations would do things like e.g. appending or copying external segments [what addIndexes*() currently does]. The second component's job would it be to manage writing the segments file and merging/deleting segments. It would know about DeletionPolicy, MergePolicy and MergeScheduler. Ideally it would provide hooks that allow users to manage external data structures and keep them in sync with Lucene's data during segment merges. API wise there are things we have to figure out, such as where the updateDocument() method would fit in, because its deletion part affects all segments, whereas the new document is only being added to the new segment. Of course these should be lower level APIs for things like parallel indexing and related use cases. That's why we should still provide easy to use APIs like today for people who don't need to care about per-segment ops during indexing. So the current IndexWriter could probably keeps most of its APIs and delegate to the new classes. -- 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-1052) Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244702#comment-13244702 ] Jan Høydahl commented on SOLR-1052: --- That's right. 3.x should be good to go now. Would very much like to get it committed to trunk as well, but I'd rather wait until someone gives it a run first. Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x-fix-tests.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate old indexDefaults and mainIndex sections and only use a new indexConfig section. 3.6: Deprecation warning if old section used 4.0: If LuceneMatchVersion before LUCENE_40 then warn (so old configs will work), else fail fast -- 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: Failing lucene-core tests in oal.junitcompat package under IntelliJ
Can you check now (on trunk), Steve? I've fixed this for Eclipse and I think it should work for Idea as well (you'll see those tests as executed but they'll be ignored internally if not running under a parent suite). If this works for you -- go ahead and apply the change to 3.x, should be a straightforward patch application (affects tests only). Dawid On Mon, Apr 2, 2012 at 11:22 PM, Steven A Rowe sar...@syr.edu wrote: I asked on the JetBrains issue about running tests matching patterns drawn from a single module: http://youtrack.jetbrains.com/issue/IDEA-78962#comment=27-315476 -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 5:15 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. I'll look into it. I remember I did some of the assume-running-nested already for Eclipse so it should be there anyway, maybe I missed something. Dawid - 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-1052) Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244715#comment-13244715 ] Simon Willnauer commented on SOLR-1052: --- bq. That's right. 3.x should be good to go now. Would very much like to get it committed to trunk as well, but I'd rather wait until someone gives it a run first. do you mean you want to wait unit 3.6 is released and its not breaking things? this makes no sense to me, we should not commit into 3.x and don't do it in trunk. this is dangerous, we should try to commit to trunk and port backwards instead. If you have time please move forward we can fix stuff on trunk easily right now. Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x-fix-tests.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate old indexDefaults and mainIndex sections and only use a new indexConfig section. 3.6: Deprecation warning if old section used 4.0: If LuceneMatchVersion before LUCENE_40 then warn (so old configs will work), else fail fast -- 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: Failing lucene-core tests in oal.junitcompat package under IntelliJ
Thanks, Dawid, I'll check now. - Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 6:05 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ Can you check now (on trunk), Steve? I've fixed this for Eclipse and I think it should work for Idea as well (you'll see those tests as executed but they'll be ignored internally if not running under a parent suite). If this works for you -- go ahead and apply the change to 3.x, should be a straightforward patch application (affects tests only). Dawid On Mon, Apr 2, 2012 at 11:22 PM, Steven A Rowe sar...@syr.edu wrote: I asked on the JetBrains issue about running tests matching patterns drawn from a single module: http://youtrack.jetbrains.com/issue/IDEA-78962#comment=27-315476 -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 5:15 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. I'll look into it. I remember I did some of the assume-running-nested already for Eclipse so it should be there anyway, maybe I missed something. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244729#comment-13244729 ] Uwe Schindler commented on LUCENE-3738: --- Commit patch or not? I have no preference. Perf is sometimes slightly better (in microbenchmark on my slow-io system always). Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244738#comment-13244738 ] Robert Muir commented on LUCENE-3738: - If there is no real measurable performance regression, can we just commit it to trunk? I really am afraid of last minute .store optimizations. Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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-3295) Binaries contain 1.6 classes
[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244741#comment-13244741
]
Uwe Schindler commented on SOLR-3295:
-
Nuke the JAR. See the comments on the TIKA issue. If the JAR is missing, the
Parser will get a ClassNotFoundException and TIKA's framework will disable it.
Your test simply uses the next possible parser, which is the plain text parser;
indexing gigabytes of horrible binary data casted to text in arbitrary
autodetected encoding :-)
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 3.6
Attachments: output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
platform: 45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{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
[jira] [Commented] (SOLR-3295) Binaries contain 1.6 classes
[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244745#comment-13244745
]
Robert Muir commented on SOLR-3295:
---
ok. the user did ask to index the gigabytes of binary data so I don't feel bad
about that :)
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 3.6
Attachments: output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
platform: 45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{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
[jira] [Commented] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244743#comment-13244743 ] Uwe Schindler commented on LUCENE-3738: --- Part of the optimization is already committed to 3.x since 4 days, this is just another round of optimization. :-) Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244748#comment-13244748 ] Uwe Schindler commented on LUCENE-3738: --- I don't care, it's committed to trunk. The new random test was committed yesterday. You are the release manager :-) Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244748#comment-13244748 ] Uwe Schindler edited comment on LUCENE-3738 at 4/2/12 10:24 PM: I don't care, it's committed to trunk. The new random test I created yesterday was committed to 3.x, but not the latest code change/opto. You are the release manager, do what you prefer :-) was (Author: thetaphi): I don't care, it's committed to trunk. The new random test was committed yesterday. You are the release manager :-) Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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: Upgrades to jars after moving to ivy.
Ant clean-jars... I complained already. In my opinion we should always remove all jars on clean. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Dawid Weiss [mailto:dawid.we...@gmail.com] Sent: Tuesday, April 03, 2012 12:26 AM To: dev@lucene.apache.org Subject: Upgrades to jars after moving to ivy. I've just modified ivy.xml to use jackson 1.7.4 and this triggered an interesting situation in which I ended up having two versions of jackson in my checkout. This begs the question of what should we be doing to remove stale JARs on an update of ivy descriptors. Should ant clean remove all the JARs? Dawid - 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: Upgrades to jars after moving to ivy.
: I've just modified ivy.xml to use jackson 1.7.4 and this triggered an : interesting situation in which I ended up having two versions of : jackson in my checkout. This begs the question of what should we be : doing to remove stale JARs on an update of ivy descriptors. Should : ant clean remove all the JARs? rmuir added clean-jars ... but i was kind of wondering hte same thing. prior to ivy, an svn up ant clean would get you into a good state because the svn up would remove the old jars ... seems like we should just make clean call clean-jars (if they *haven't* changed they'll still be in your ivy cache) -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3295) Binaries contain 1.6 classes
[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated SOLR-3295:
--
Attachment: SOLR-3295.patch
simple patch
Binaries contain 1.6 classes
Key: SOLR-3295
URL: https://issues.apache.org/jira/browse/SOLR-3295
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Robert Muir
Priority: Minor
Fix For: 3.6
Attachments: SOLR-3295.patch, output.log
I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
the checkout of branch_3x. To my surprise there is a JAR which contains Java
1.6 code:
{noformat}
Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
platform: 45.3-50.0
Number of classes : 60
Classes are :
c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
ucar/unidata/geoloc/Bearing.class
...
{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
Re: Upgrades to jars after moving to ivy.
On Mon, Apr 2, 2012 at 6:29 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : I've just modified ivy.xml to use jackson 1.7.4 and this triggered an : interesting situation in which I ended up having two versions of : jackson in my checkout. This begs the question of what should we be : doing to remove stale JARs on an update of ivy descriptors. Should : ant clean remove all the JARs? rmuir added clean-jars ... but i was kind of wondering hte same thing. prior to ivy, an svn up ant clean would get you into a good state because the svn up would remove the old jars ... seems like we should just make clean call clean-jars (if they *haven't* changed they'll still be in your ivy cache) This is way too much effort for what you will get. effort better spent removing lib/ and 'copies of jars' totally and instead having ivy just put this in the classpath. The reason it is the way it is: is to not break packaging etc tasks. IFF someone wants to open an issue and clean all this up and fix and test all of the packaging logic, thats fine for trunk. but its not ok for the branch. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Failing lucene-core tests in oal.junitcompat package under IntelliJ
Cool, no more failing tests! I'll backport to branch_3x. -Original Message- From: Steven A Rowe [mailto:sar...@syr.edu] Sent: Monday, April 02, 2012 6:10 PM To: dev@lucene.apache.org Subject: RE: Failing lucene-core tests in oal.junitcompat package under IntelliJ Thanks, Dawid, I'll check now. - Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 6:05 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ Can you check now (on trunk), Steve? I've fixed this for Eclipse and I think it should work for Idea as well (you'll see those tests as executed but they'll be ignored internally if not running under a parent suite). If this works for you -- go ahead and apply the change to 3.x, should be a straightforward patch application (affects tests only). Dawid On Mon, Apr 2, 2012 at 11:22 PM, Steven A Rowe sar...@syr.edu wrote: I asked on the JetBrains issue about running tests matching patterns drawn from a single module: http://youtrack.jetbrains.com/issue/IDEA-78962#comment=27-315476 -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Monday, April 02, 2012 5:15 PM To: dev@lucene.apache.org Subject: Re: Failing lucene-core tests in oal.junitcompat package under IntelliJ No rush. I'll make an issue in a day or two if nobody else knows of a configuration fix. I'll look into it. I remember I did some of the assume-running-nested already for Eclipse so it should be there anyway, maybe I missed something. Dawid - 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: Upgrades to jars after moving to ivy.
prior to ivy, an svn up ant clean would get you into a good state I use git so I can also do git clean -xfd and this restores anything not in version control but I agree that it would be more intuitive to have 'ant clean' remove jars as well if they're restored quickly from cache anyway. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Upgrades to jars after moving to ivy.
This is way too much effort for what you will get. effort better spent
Isn't it like adding one line to 'clean' target though?
delete dir=${basedir} includes=**/*.jar /
removing lib/ and 'copies of jars' totally
and instead having ivy just put this in the classpath.
This isn't going to be just about classpaths -- it's going to be about
packaging, license checks, coordinates of license files wrt JAR files
etc. I agree it's a larger issue and I'm not pressing for it to happen
on 3.x, but ''ant clean' seems to be better than nothing and seems
relatively simple unless I'm missing something.
D.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244770#comment-13244770 ] Robert Muir commented on LUCENE-3738: - Lets resolve the issue. Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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: Upgrades to jars after moving to ivy.
On Mon, Apr 2, 2012 at 6:36 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
This is way too much effort for what you will get. effort better spent
Isn't it like adding one line to 'clean' target though?
delete dir=${basedir} includes=**/*.jar /
removing lib/ and 'copies of jars' totally
and instead having ivy just put this in the classpath.
This isn't going to be just about classpaths -- it's going to be about
packaging, license checks, coordinates of license files wrt JAR files
etc. I agree it's a larger issue and I'm not pressing for it to happen
on 3.x, but ''ant clean' seems to be better than nothing and seems
relatively simple unless I'm missing something.
Right, like reviewing all packaging tasks to see if they ever call
'clean' before they do anything like generate maven artifacts or
create binary distribution packages.
Because if this happens, then the binary distribution is screwed. I'm
not willing to risk it.
--
lucidimagination.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Upgrades to jars after moving to ivy.
Additionally, removing all JARs on ant clean is hoorible for IDE users, because those would loose JARs from their classpath. As Robert said, for Eclipse it might be better to depend on IvyDE plugin, which works great and does the same like the building class-path from Ivy cache (ivy:cachepath/ivy:cachefileset). You right click on the ivy.xml file and Eclipse adds all referenced JARs to your internal build path. It then appears like a library in Eclipse sense. So +1 on a new issue to cleanup the build in trunk to no longer copy any JARs around (nuke ivy-resolve task) and instead build all classpath with ivy:cachepath property=.../ and build all ZIPs/WARs/... with ivy:cachefileset/ inside the zip tasks. - 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: Tuesday, April 03, 2012 12:31 AM To: dev@lucene.apache.org Subject: Re: Upgrades to jars after moving to ivy. On Mon, Apr 2, 2012 at 6:29 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : I've just modified ivy.xml to use jackson 1.7.4 and this triggered an : interesting situation in which I ended up having two versions of : jackson in my checkout. This begs the question of what should we be : doing to remove stale JARs on an update of ivy descriptors. Should : ant clean remove all the JARs? rmuir added clean-jars ... but i was kind of wondering hte same thing. prior to ivy, an svn up ant clean would get you into a good state because the svn up would remove the old jars ... seems like we should just make clean call clean-jars (if they *haven't* changed they'll still be in your ivy cache) This is way too much effort for what you will get. effort better spent removing lib/ and 'copies of jars' totally and instead having ivy just put this in the classpath. The reason it is the way it is: is to not break packaging etc tasks. IFF someone wants to open an issue and clean all this up and fix and test all of the packaging logic, thats fine for trunk. but its not ok for the branch. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Upgrades to jars after moving to ivy.
See my previous comment... Horrible for DIE users at the moment.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of
Dawid Weiss
Sent: Tuesday, April 03, 2012 12:37 AM
To: dev@lucene.apache.org
Subject: Re: Upgrades to jars after moving to ivy.
This is way too much effort for what you will get. effort better spent
Isn't it like adding one line to 'clean' target though?
delete dir=${basedir} includes=**/*.jar /
removing lib/ and 'copies of jars' totally and instead having ivy just
put this in the classpath.
This isn't going to be just about classpaths -- it's going to be about
packaging,
license checks, coordinates of license files wrt JAR files etc. I agree it's
a larger
issue and I'm not pressing for it to happen on 3.x, but ''ant clean' seems to
be
better than nothing and seems relatively simple unless I'm missing something.
D.
-
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] [Resolved] (LUCENE-3738) Be consistent about negative vInt/vLong
[ https://issues.apache.org/jira/browse/LUCENE-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3738. --- Resolution: Fixed Latest code change not backported. Be consistent about negative vInt/vLong --- Key: LUCENE-3738 URL: https://issues.apache.org/jira/browse/LUCENE-3738 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Uwe Schindler Priority: Blocker Fix For: 3.6, 4.0 Attachments: ByteArrayDataInput.java.patch, LUCENE-3738-improvement.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch, LUCENE-3738.patch Today, write/readVInt allows a negative int, in that it will encode and decode correctly, just horribly inefficiently (5 bytes). However, read/writeVLong fails (trips an assert). I'd prefer that both vInt/vLong trip an assert if you ever try to write a negative number... it's badly trappy today. But, unfortunately, we sometimes rely on this... had we had this assert in 'since the beginning' we could have avoided that. So, if we can't add that assert in today, I think we should at least fix readVLong to handle negative longs... but then you quietly spend 9 bytes (even more trappy!). -- 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: Upgrades to jars after moving to ivy.
On Mon, Apr 2, 2012 at 6:40 PM, Uwe Schindler u...@thetaphi.de wrote: So +1 on a new issue to cleanup the build in trunk to no longer copy any JARs around (nuke ivy-resolve task) and instead build all classpath with ivy:cachepath property=.../ and build all ZIPs/WARs/... with ivy:cachefileset/ inside the zip tasks. +1... for trunk -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1052) Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244779#comment-13244779 ] Jan Høydahl commented on SOLR-1052: --- I'm of course not suggesting to use a 3.x release as test before committing to trunk :-) The rule is to do trunk first. In this case since this is a deprecation patch with different behaviour in 3.6 and 4.0, we fleshed out the 3.x part first this time. All trunk tests pass for me - so I will commit to trunk now to get any uncaught issues out of the way before easter.. Deprecate/Remove indexDefaults and mainIndex in favor of indexConfig in solrconfig.xml Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x-fix-tests.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate old indexDefaults and mainIndex sections and only use a new indexConfig section. 3.6: Deprecation warning if old section used 4.0: If LuceneMatchVersion before LUCENE_40 then warn (so old configs will work), else fail fast -- 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-3307) DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011
[ https://issues.apache.org/jira/browse/SOLR-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3307: - Attachment: SOLR-3307.patch Bernd, Here's a patch that passed your new unit test. Do you think you can give it a quick review? All other DIH tests pass too, including Mikhail's new tests from SOLR-3011. If all's good, I'd like to try and slip this into 3.6 as this is to fix a 3.6-only regression (feature is removed in Trunk). DIH FileListEntityProcessor not multi-threading after applying patch SOLR-3011 -- Key: SOLR-3307 URL: https://issues.apache.org/jira/browse/SOLR-3307 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6 Reporter: Bernd Fehling Assignee: James Dyer Fix For: 3.6 Attachments: SOLR-3307-UnitTest.patch, SOLR-3307.patch As reported in issue SOLR-3011 the FileListEntityProcessor is not recursing through all sub-directories and files after applying SOLR-3011.patch. -- 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
