[jira] [Updated] (LUCENENET-476) ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
[
https://issues.apache.org/jira/browse/LUCENENET-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-476:
--
Issue Type: Bug (was: Sub-task)
Parent: (was: LUCENENET-446)
ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
-
Key: LUCENENET-476
URL: https://issues.apache.org/jira/browse/LUCENENET-476
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4
Environment: Visual Basic .Net
Reporter: Jon
Fix For: Lucene.Net 3.0.3
The field TopDocs.scoreDocs has been made obsolete and a new property
TopDocs.ScoreDocs has been added. VB.Net is case insensitive, so both resolve
to the same name, resulting in the following error message:
{quote}
'ScoreDocs' is ambiguous because multiple kinds of members with this name
exist in class 'Lucene.Net.Search.TopDocs'
{quote}
--
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
SOLR automatic failover with Zookeeper
Hi folks, Is there a way to configure Solr master -failure using Zookeoper? I heard Grant did some work on this... Ankit
Re: Warning with fall-through in SimpleText
we can just duplicate the logic instead of falling through. simon On Sun, Mar 18, 2012 at 1:01 PM, Uwe Schindler u...@thetaphi.de wrote: Hi, is this wanted? common.compile-core: [mkdir] Created dir: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\build\core\classes\java [javac] Compiling 632 source files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\build\core\classes\java [javac] C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\core\src\java\org\apache\luce ne\codecs\simpletext\SimpleTextDocValuesConsumer.java:109: warning: [fallthrough] possible fall-through into case [javac] case VAR_INTS: [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] 1 warning [copy] Copying 2 files to C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\build\core\classes\java - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de - 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
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2019 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2019/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=91 closes=90 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 closes=90 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) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=91 closes=90 at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) ... 4 more Build Log (for compile errors): [...truncated 9926 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
How to extend TermInfo ?
Hi, guys: I have needs to add a new data filed in TermInfo. refer to here: http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/fileformats.html#TermDictionary Do i need to change the term FST build process? Anybody had done this kind of modification before? Thanks,
Re: Weird solr errors?
Thanks Ryan, For output readability, it would be great to be able to hide the output when we *know* it is expected. Yes, that's what I meant. Is that possible? Is there a better way to test for exceptions you want to get thrown? I don't think there is a better way. On the LUCENE-3808 branch the console output from tests/ suites only gets emitted to the console when a suite fails (there is a suite level error or any of its tests fails). Full output is sent to another file so it is always available for inspection, but the output log from an ant run is much, much cleaner to look at. Another way to do it would be to suppress (enable buffering) in the logging handler and skip part of the logs if the test passes and we know a code block will be polluting logs with (expected) exception. I think LUCENE-3808 is a cleaner approach as it doesn't attempt to clean anything yet provides a sensible alternative on the console... If it keeps bothering me I'll try to fix it using the approach above. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: How to extend TermInfo ?
It is not easy to add new per-term metadata in 3.x. But in trunk (to eventually be 4.0)... you can make your own codec and store additional per-term metadata. What kind of metadata are you wanting to store...? Mike McCandless http://blog.mikemccandless.com On Mon, Mar 19, 2012 at 2:42 AM, lukai lukai1...@gmail.com wrote: Hi, guys: I have needs to add a new data filed in TermInfo. refer to here:http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/fileformats.html#Term Dictionary Do i need to change the term FST build process? Anybody had done this kind of modification before? Thanks, - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
ant dist-maven creates OOM (PermGen space) on 3.x
ant -Dversion=3.6.0 prepare-release ... dist-maven: [artifact:install-provider] Installing provider: org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:323) at org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:170) at org.apache.tools.ant.Project.fireBuildFinished(Project.java:2037) at org.apache.tools.ant.Main.runBuild(Main.java:778) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) PermGen space 3.x r1302380 java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Apache Ant version 1.7.1 compiled on September 3 2011 -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2424) extracted text from tika has no spaces
[ https://issues.apache.org/jira/browse/SOLR-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-2424. -- Resolution: Fixed Fix Version/s: 3.5 Apparently only a problem with Tika 0.8, which would have affected versions 3.2, 3.3 and 3.4 extracted text from tika has no spaces -- Key: SOLR-2424 URL: https://issues.apache.org/jira/browse/SOLR-2424 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 3.1 Reporter: Yonik Seeley Fix For: 3.5 Attachments: ET2000 Service Manual.pdf Try this: curl http://localhost:8983/solr/update/extract?extractOnly=truewt=jsonindent=true; -F tutorial=@tutorial.pdf And you get text output w/o spaces: ThisdocumentcoversthebasicsofrunningSolru... -- 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: ant dist-maven creates OOM (PermGen space) on 3.x
The 'hudson hack' works here, e.g. instead ANT_OPTS=-Xmx256m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128M ant -Dversion=3.6.0 prepare-release. I'll update the ReleaseTODO for now on the wiki, but if anyone has ideas for a better solution so this task works 'out of box', that would be great. On Mon, Mar 19, 2012 at 7:42 AM, Robert Muir rcm...@gmail.com wrote: ant -Dversion=3.6.0 prepare-release ... dist-maven: [artifact:install-provider] Installing provider: org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-7:runtime java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:323) at org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:170) at org.apache.tools.ant.Project.fireBuildFinished(Project.java:2037) at org.apache.tools.ant.Main.runBuild(Main.java:778) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) PermGen space 3.x r1302380 java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Apache Ant version 1.7.1 compiled on September 3 2011 -- lucidimagination.com -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: SOLR automatic failover with Zookeeper
Hmmm, take a look at SolrCloud, most all of this has been done. Start with: http://wiki.apache.org/solr/SolrCloud BTW, the Solr User's list gets a lot more traffic, you might get answers there a lot faster. See: http://lucene.apache.org/solr/discussion.html Best Erick On Mon, Mar 19, 2012 at 12:15 AM, Ankit Bhatnagar ankit_impress...@yahoo.com wrote: Hi folks, Is there a way to configure Solr master -failure using Zookeoper? I heard Grant did some work on this... Ankit - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2022 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2022/ 1 tests failed. REGRESSION: org.apache.lucene.search.grouping.GroupFacetCollectorTest.testRandom Error Message: null Stack Trace: java.lang.NullPointerException at org.apache.lucene.search.grouping.term.TermGroupFacetCollector$MV.setNextReader(TermGroupFacetCollector.java:249) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:505) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297) at org.apache.lucene.search.grouping.GroupFacetCollectorTest.testRandom(GroupFacetCollectorTest.java:259) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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:768) Build Log (for compile errors): [...truncated 5557 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2424) extracted text from tika has no spaces
[ https://issues.apache.org/jira/browse/SOLR-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232611#comment-13232611 ] Yonik Seeley commented on SOLR-2424: Yes, I just confirmed that the command given in the description no longer results in text w/o spaces. extracted text from tika has no spaces -- Key: SOLR-2424 URL: https://issues.apache.org/jira/browse/SOLR-2424 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 3.1 Reporter: Yonik Seeley Fix For: 3.5 Attachments: ET2000 Service Manual.pdf Try this: curl http://localhost:8983/solr/update/extract?extractOnly=truewt=jsonindent=true; -F tutorial=@tutorial.pdf And you get text output w/o spaces: ThisdocumentcoversthebasicsofrunningSolru... -- 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-3882) maven-metadata.xml's are only hashed but not signed
maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3882: Attachment: LUCENE-3882.patch patch against branch_3x, just adds **/*.xml to the patterns for signing. maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3253) defaultCoreName mapped as singlecore in UI
[ https://issues.apache.org/jira/browse/SOLR-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232619#comment-13232619 ] Markus Jelsma commented on SOLR-3253: - It indeed sounds like it! defaultCoreName mapped as singlecore in UI -- Key: SOLR-3253 URL: https://issues.apache.org/jira/browse/SOLR-3253 Project: Solr Issue Type: Bug Components: web gui Environment: 4.0-SNAPSHOT 1301480 - markus - 2012-03-16 14:09:18 Reporter: Markus Jelsma Priority: Minor We have four cores A,B,C,D and no value for defaultCoreName in solr.xml. In the UI we see the four cores properly listed. When we assign a value A to defaultCoreName, core A is no longer named as A in both UI and Solr built URL's. Instead, it's now called singlecore. Normal request handlers still work with the real core name so only URL's in the UI are affected. -- 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] (LUCENENET-476) ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
ScoreDocs in TopDocs is ambiguos when using Visual Basic .Net
-
Key: LUCENENET-476
URL: https://issues.apache.org/jira/browse/LUCENENET-476
Project: Lucene.Net
Issue Type: Bug
Components: Lucene.Net Core
Affects Versions: Lucene.Net 2.9.4
Environment: Visual Basic .Net
Reporter: Jon
The field TopDocs.scoreDocs has been made obsolete and a new property
TopDocs.ScoreDocs has been added. VB.Net is case insensitive, so both resolve
to the same name, resulting in the following error message:
{quote}
'ScoreDocs' is ambiguous because multiple kinds of members with this name exist
in class 'Lucene.Net.Search.TopDocs'
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8
[
https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232622#comment-13232622
]
Yonik Seeley commented on SOLR-3159:
From that link, it looks like it should probably be:
{code}
Call name=setAttribute
Argorg.eclipse.jetty.server.Request.maxFormContentSize/Arg
Arg20/Arg
/Call
{code}
Can anyone test and confirm this works?
bq. These are the same settings we had for jetty 6, but I do not know if this
is still the best choice. In particular, I'm not sure about the
.bio.SocketConnector vs .nio.SelectChannelConnector
The NIO connector was causing intermittent failures on Jenkins. I have no idea
if the bugs were ever found/fixed in Jetty land - but it's a risk. It would be
nice to move to the NIO connector if it is now stable though, since it could
possibly allow for better logging/debugging (i.e. if we can specify our own
thread pool to handle requests such that we can tell different jetty instances
apart during logging).
Upgrade to Jetty 8
--
Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3159-maven.patch
Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is equivalent,
I think we should switch to Jetty 8.
--
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-3253) defaultCoreName mapped as singlecore in UI
[ https://issues.apache.org/jira/browse/SOLR-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-3253. -- Resolution: Duplicate See: SOLR-2605 defaultCoreName mapped as singlecore in UI -- Key: SOLR-3253 URL: https://issues.apache.org/jira/browse/SOLR-3253 Project: Solr Issue Type: Bug Components: web gui Environment: 4.0-SNAPSHOT 1301480 - markus - 2012-03-16 14:09:18 Reporter: Markus Jelsma Priority: Minor We have four cores A,B,C,D and no value for defaultCoreName in solr.xml. In the UI we see the four cores properly listed. When we assign a value A to defaultCoreName, core A is no longer named as A in both UI and Solr built URL's. Instead, it's now called singlecore. Normal request handlers still work with the real core name so only URL's in the UI are affected. -- 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
Using term offsets for hit highlighting
Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. All pointers gratefully received! Thanks, Alan Woodward
Re: Using term offsets for hit highlighting
On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Using term offsets for hit highlighting
Cool, thanks Robert. I'll take a look at the JIRA ticket. On 19 Mar 2012, at 14:44, Robert Muir wrote: On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- 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] (SOLR-3011) DIH MultiThreaded bug
[
https://issues.apache.org/jira/browse/SOLR-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232650#comment-13232650
]
James Dyer commented on SOLR-3011:
--
{quote}
what is the importance of delta import scenario? I see it can be done via full
import instead
{quote}
This just provides two ways you can set up your deltas. Personally I like to
use full-import w/ clean=false to do deltas. Its much more flexible. With
that said, people use the other way and it works. The bad thing, I think, is
it is not documented that threads doesn't work with it. Also, surely the
code can be cleaned up to not be an entirely different branch from
full-import.
{quote}
It's hard to maintain code ever.
{quote}
This is why I think removing threads in trunk is still the way to go. This
will give us a good starting point for improving the code. We can add add a
better-designed version of threads later.
With that said, I think you've probably fixed threads for a lot of use-cases.
Why can't we back-port this to 3.x and document for the users what works and
doesn't work with threads, with warnings to test thoroughly before going to
production? If it means back-porting the cache refactorings first, so be it.
I know you were thinking we really should start over with Ultimate DIH.
That's fine if people want to do that. But I'm using the existing DIH for some
pretty complex things and it works great. My issue with DIH is not that it
isn't a good product. Its just that it needs some work internally if we're
going to be able to continue to improve it from here.
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, 4.0
Reporter: Mikhail Khludnev
Priority: Minor
Fix For: 4.0
Attachments: 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] [Commented] (LUCENE-3882) maven-metadata.xml's are only hashed but not signed
[
https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232655#comment-13232655
]
Steven Rowe commented on LUCENE-3882:
-
Robert, I think it's not necessary/useful to sign these files.
In Maven Central, many projects don't have signatures for this file, e.g.
http://search.maven.org/#browse|1946773355 ({{org.apache.apache}}, the Apache
parent POM.
I think the issue is that when Maven artifacts are uploaded, for each artifact,
entries from the maven-metadata.xml file's contents are merged with the
existing version of that file. As a result, the signature will no longer apply.
Maven-core is an example of a project where they used to sign this file, then
stopped doing it, but left the signature in the repo:
[http://search.maven.org/#browse|-1493030540]. Note that the
{{maven-metadata.xml.asc}} file is dated 2006.
maven-metadata.xml's are only hashed but not signed
---
Key: LUCENE-3882
URL: https://issues.apache.org/jira/browse/LUCENE-3882
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Reporter: Robert Muir
Fix For: 3.6, 4.0
Attachments: LUCENE-3882.patch
we only produce .sha/.md5 for these files, but not .asc
--
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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232658#comment-13232658 ] Robert Muir commented on LUCENE-3882: - Steven, thanks. OK to cancel this issue then? I just thought it was strange to see .md5/.sha1 without the corresponding .asc maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232661#comment-13232661 ] Steven Rowe commented on LUCENE-3882: - bq. OK to cancel this issue then? +1 maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3882. - Resolution: Not A Problem See Steven's explanation for why this isnt useful. maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232664#comment-13232664 ] Uwe Schindler commented on LUCENE-3882: --- But then also the md5/sha1's are useless as those get updated during merging, too? maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232664#comment-13232664 ] Uwe Schindler edited comment on LUCENE-3882 at 3/19/12 3:05 PM: But then also the md5/sha1's are useless as those don't get updated during merging, too? was (Author: thetaphi): But then also the md5/sha1's are useless as those get updated during merging, too? maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232668#comment-13232668 ] Robert Muir commented on LUCENE-3882: - OOps i resolved before seeing Uwe's comment. Steven should we fix this to not have .md5/.sha1 too? or are those useful? maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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-3882) maven-metadata.xml's are only hashed but not signed
[
https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232670#comment-13232670
]
Steven Rowe commented on LUCENE-3882:
-
These hashes appear to be regenerated by the repository (I checked the
Maven-core hashes and they matched), and as a result, the hashes submitted to
the repo are ignored.
However, some people use the results of {{generate-maven-artifacts}} directly,
in which case these hashes may provide some utility? And I don't think they're
doing any harm.
So I'm -0 to stop making hashes for these files.
maven-metadata.xml's are only hashed but not signed
---
Key: LUCENE-3882
URL: https://issues.apache.org/jira/browse/LUCENE-3882
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Reporter: Robert Muir
Fix For: 3.6, 4.0
Attachments: LUCENE-3882.patch
we only produce .sha/.md5 for these files, but not .asc
--
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=13232681#comment-13232681 ] Mikhail Khludnev commented on SOLR-3011: bq. If it means back-porting the cache refactorings first, so be it. ah, I've got your point. sure. In this case it will be vanilla cherrypicking 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, 4.0 Reporter: Mikhail Khludnev Priority: Minor Fix For: 4.0 Attachments: 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] [Commented] (LUCENE-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232685#comment-13232685 ] Steven Rowe commented on LUCENE-3882: - Maven Ant Tasks generates the hashes, so we would have to delete them after they are created. maven-metadata.xml's are only hashed but not signed --- Key: LUCENE-3882 URL: https://issues.apache.org/jira/browse/LUCENE-3882 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Fix For: 3.6, 4.0 Attachments: LUCENE-3882.patch we only produce .sha/.md5 for these files, but not .asc -- 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: Using term offsets for hit highlighting
Alan, you made my day! The branch is kind of outdated but I looked at it lately and I can certainly help to get it up to speed. The feature in that branch is quite a big one and its in a very early stage. Still I want to encourage you to take a look and work on it. I promise all my help with the issues! let me know if you have questions! simon On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Cool, thanks Robert. I'll take a look at the JIRA ticket. On 19 Mar 2012, at 14:44, Robert Muir wrote: On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- 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: Using term offsets for hit highlighting
Have you marked that for GSOC? Would be a good idea! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Willnauer [mailto:simon.willna...@googlemail.com] Sent: Monday, March 19, 2012 4:43 PM To: dev@lucene.apache.org Subject: Re: Using term offsets for hit highlighting Alan, you made my day! The branch is kind of outdated but I looked at it lately and I can certainly help to get it up to speed. The feature in that branch is quite a big one and its in a very early stage. Still I want to encourage you to take a look and work on it. I promise all my help with the issues! let me know if you have questions! simon On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Cool, thanks Robert. I'll take a look at the JIRA ticket. On 19 Mar 2012, at 14:44, Robert Muir wrote: On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- 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
Re: Using term offsets for hit highlighting
On Mon, Mar 19, 2012 at 4:50 PM, Uwe Schindler u...@thetaphi.de wrote: Have you marked that for GSOC? Would be a good idea! yes I did - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Willnauer [mailto:simon.willna...@googlemail.com] Sent: Monday, March 19, 2012 4:43 PM To: dev@lucene.apache.org Subject: Re: Using term offsets for hit highlighting Alan, you made my day! The branch is kind of outdated but I looked at it lately and I can certainly help to get it up to speed. The feature in that branch is quite a big one and its in a very early stage. Still I want to encourage you to take a look and work on it. I promise all my help with the issues! let me know if you have questions! simon On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Cool, thanks Robert. I'll take a look at the JIRA ticket. On 19 Mar 2012, at 14:44, Robert Muir wrote: On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- 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] [Created] (LUCENE-3883) Analysis for Irish
Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: LUCENE-3883.patch Patch adding Irish analysis Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: (was: LUCENE-3883.patch) Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: LUCENE-3883.patch Patch, redone from top level of svn. Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-MAVEN] Lucene-Solr-Maven-trunk #429: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/429/ 10 tests failed. FAILED: org.apache.solr.handler.clustering.DistributedClusteringComponentTest.testDistribSearch Error Message: class javax.servlet.FilterRegistration's signer information does not match signer information of other classes in the same package Stack Trace: java.lang.SecurityException: class javax.servlet.FilterRegistration's signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:787) at java.lang.ClassLoader.preDefineClass(ClassLoader.java:502) at java.lang.ClassLoader.defineClass(ClassLoader.java:628) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.eclipse.jetty.servlet.ServletContextHandler.init(ServletContextHandler.java:129) at org.eclipse.jetty.servlet.ServletContextHandler.init(ServletContextHandler.java:109) at org.apache.solr.client.solrj.embedded.JettySolrRunner.init(JettySolrRunner.java:126) at org.apache.solr.client.solrj.embedded.JettySolrRunner.init(JettySolrRunner.java:74) at org.apache.solr.BaseDistributedSearchTestCase.createJetty(BaseDistributedSearchTestCase.java:250) at org.apache.solr.BaseDistributedSearchTestCase.createServers(BaseDistributedSearchTestCase.java:182) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:669) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
[jira] [Commented] (LUCENE-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232706#comment-13232706 ] Robert Muir commented on LUCENE-3883: - Thanks Jim! This looks really nicely done... Out of curiousity could you share your snowball rules (the .sbl) with us? Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232712#comment-13232712 ] Uwe Schindler commented on LUCENE-3883: --- Hi, very funny lowercase filter! :-) One thing: It does not actually ArrayIndexOutOfBoundsEx in the filter because of the way how CharTermAttributeImpl is implemented internally, but theoretically there is a length check missing. The nUpper/tUpper stuff can get out of bounds if the length of term in 0 or 1 (which are valid length). But thats only a minor complaint about the code. Otherwise looks great. Just appearing from no irish support at all! really needed! :-) Uwe Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3884) Move elisionfilter out of .fr package
Move elisionfilter out of .fr package - Key: LUCENE-3884 URL: https://issues.apache.org/jira/browse/LUCENE-3884 Project: Lucene - Java Issue Type: Task Components: modules/analysis Reporter: Robert Muir Steven Rowe noted this a while back, but I forgot to open an issue: This is generally useful for handling contractions. We already use this filter for french/italian/catalan. Now we also have a contribution for irish (LUCENE-3883) that uses it too. I think we should put this in o.a.l.analysis.util instead. -- 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-3884) Move elisionfilter out of .fr package
[ https://issues.apache.org/jira/browse/LUCENE-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232718#comment-13232718 ] Uwe Schindler commented on LUCENE-3884: --- +1 We had the same idea at same time :-) Move elisionfilter out of .fr package - Key: LUCENE-3884 URL: https://issues.apache.org/jira/browse/LUCENE-3884 Project: Lucene - Java Issue Type: Task Components: modules/analysis Reporter: Robert Muir Steven Rowe noted this a while back, but I forgot to open an issue: This is generally useful for handling contractions. We already use this filter for french/italian/catalan. Now we also have a contribution for irish (LUCENE-3883) that uses it too. I think we should put this in o.a.l.analysis.util instead. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232717#comment-13232717 ] Robert Muir commented on LUCENE-3883: - By the way I created LUCENE-3884 to move the ElisionFilter out of the french package into a more general .util package. That doesnt need to hold up this issue: it just reminded me we should move it because its not really french-specific. Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: irish.sbl Irish snowball script Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch, irish.sbl Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232721#comment-13232721 ] Jim Regan commented on LUCENE-3883: --- Yeah, it's quite an odd thing (Scots Gaelic has a similar phenomenon, but they consistently keep the hyphen), but it does help with the stemmer in those cases to know that the t or n at the start of the word is due only to mutation. Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch, irish.sbl Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232732#comment-13232732 ] Jim Regan commented on LUCENE-3883: --- I'm not sure if I actually needed to use the ElisionFilter, because the stemmer handles those - because of the initial mutation in Irish, trimming the start of the word is more important than trimming the end. I was copying the Catalan analyser, and using ElisionFilter seemed like The Thing To Do. Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch, irish.sbl Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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: Using term offsets for hit highlighting
I posted a patch with a Collector somewhat similar to what you described, Alan - it's attached to one of the sub-issues https://issues.apache.org/jira/browse/LUCENE-3318. It is in a fairly complete alpha state, but has seen no production use of course, since it relies on the remainder of the unfinished work in that branch. It works by creating a TokenStream based on match positions returned from the query and passing that to the existing Highlighter. Please feel free to get in touch if you decide to look into that and have questions. -Mike On 03/19/2012 11:51 AM, Simon Willnauer wrote: On Mon, Mar 19, 2012 at 4:50 PM, Uwe Schindleru...@thetaphi.de wrote: Have you marked that for GSOC? Would be a good idea! yes I did - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Willnauer [mailto:simon.willna...@googlemail.com] Sent: Monday, March 19, 2012 4:43 PM To: dev@lucene.apache.org Subject: Re: Using term offsets for hit highlighting Alan, you made my day! The branch is kind of outdated but I looked at it lately and I can certainly help to get it up to speed. The feature in that branch is quite a big one and its in a very early stage. Still I want to encourage you to take a look and work on it. I promise all my help with the issues! let me know if you have questions! simon On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Cool, thanks Robert. I'll take a look at the JIRA ticket. On 19 Mar 2012, at 14:44, Robert Muir wrote: On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward alan.woodw...@romseysoftware.co.uk wrote: Hello, The project I'm currently working on requires the reporting of exact hit positions from some pretty hairy queries, not all of which are covered by the existing highlighter modules. I'm working round this by translating everything into SpanQueries, and using the getSpans() method to locate hits (I've extended the Spans interface to make term offsets available - see https://issues.apache.org/jira/browse/LUCENE-3826). This works for our use-case, but isn't terribly efficient, and obviously isn't applicable to non-Span queries. I've seen a bit of chatter on the list about using term offsets to provide accurate highlighting in Lucene. I'm going to have a couple of weeks free in April, and I thought I might have a go at implementing this. Mainly I'm wondering if there's already been thoughts about how to do it. My current thoughts are to somehow extend the Weight and Scorer interface to make term offsets available; to get highlights for a given set of documents, you'd essentially run the query again, with a filter on just the documents you want highlighted, and have a custom collector that gets the term offsets in place of the scores. Hi Alan, Simon started some initial work on https://issues.apache.org/jira/browse/LUCENE-2878 Some work and prototypes were done in a branch, but it might be lagging behind trunk a bit. Additionally at the time it was first done, I think we didn't yet support offsets in the postings lists. We've since added this and several codecs support it. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2949) QueryElevationComponent does not fully support distributed search
[ https://issues.apache.org/jira/browse/SOLR-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-2949. Resolution: Fixed Fix Version/s: (was: 3.6) Committed fix (the comparator was looking at \_elevate\_ and using that as the id field) QueryElevationComponent does not fully support distributed search - Key: SOLR-2949 URL: https://issues.apache.org/jira/browse/SOLR-2949 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Mark Miller Priority: Minor Fix For: 4.0 Attachments: SOLR-2949.patch, SOLR-2949.patch The QueryElevationComponent does not fully support distributed search. Add tests and make a fix for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3720) OOM in TestBeiderMorseFilter.testRandom
[ https://issues.apache.org/jira/browse/LUCENE-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232738#comment-13232738 ] Robert Muir commented on LUCENE-3720: - Thanks so much for digging into this Thomas! When the release comes out we can add support and tests for the new encoder too. OOM in TestBeiderMorseFilter.testRandom --- Key: LUCENE-3720 URL: https://issues.apache.org/jira/browse/LUCENE-3720 Project: Lucene - Java Issue Type: Test Components: modules/analysis Affects Versions: 3.6, 4.0 Reporter: Robert Muir This has been OOM'ing a lot... we should see why, its likely a real bug. ant test -Dtestcase=TestBeiderMorseFilter -Dtestmethod=testRandom -Dtests.seed=2e18f456e714be89:310bba5e8404100d:-3bd11277c22f4591 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=ISO8859-1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: LUCENE-3883.patch New version of patch, also checking that chLen (array length) 1 Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch, LUCENE-3883.patch, irish.sbl Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3883) Analysis for Irish
[ https://issues.apache.org/jira/browse/LUCENE-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Regan updated LUCENE-3883: -- Attachment: (was: LUCENE-3883.patch) Analysis for Irish -- Key: LUCENE-3883 URL: https://issues.apache.org/jira/browse/LUCENE-3883 Project: Lucene - Java Issue Type: New Feature Components: modules/analysis Reporter: Jim Regan Priority: Trivial Labels: analysis, newbie Attachments: LUCENE-3883.patch, irish.sbl Adds analysis for Irish. The stemmer is generated from a snowball stemmer. I've sent it to Martin Porter, who says it will be added during the week. -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions
[
https://issues.apache.org/jira/browse/SOLR-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer reassigned SOLR-2124:
Assignee: James Dyer
SEVERE exceptions are being logged for expected PingRequestHandler
SERVICE_UNAVAILABLE exceptions
-
Key: SOLR-2124
URL: https://issues.apache.org/jira/browse/SOLR-2124
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: James Dyer
Fix For: 3.6, 4.0
Attachments: SOLR-2124.patch
As reported by a user, if you use the PingRequestHandler, and the
corrisponding helthcheck file doesn't exist (and expected situation when a
server is out of rotation) Solr is logging a SEVERE error...
{noformat}
SEVERE: org.apache.solr.common.SolrException: Service disabled
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
This is in spite of hte fact that PingRequestHandler explicitly sets the
alreadyLogged boolean to true in the SolrException constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions
[
https://issues.apache.org/jira/browse/SOLR-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-2124:
-
Attachment: SOLR-2124.patch
Patch changes SolrException to not log the exception if its 503/Service
Unavailable. In all cases this is used, the 503 SE is thrown intentionally.
That is, its really not a Runtime-style exception at all. There is nothing to
debug and a stack trace is no going to be helpful.
For PingRequestHandler, this is what it logs AFTER the patch:
12:33:45,836 INFO [SolrCore] [] webapp=/Solr_Trunk path=/admin/ping params={}
status=503 QTime=0
(compare with the full stack trace in the Description)
I will commit shortly if nobody objects.
SEVERE exceptions are being logged for expected PingRequestHandler
SERVICE_UNAVAILABLE exceptions
-
Key: SOLR-2124
URL: https://issues.apache.org/jira/browse/SOLR-2124
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Fix For: 3.6, 4.0
Attachments: SOLR-2124.patch
As reported by a user, if you use the PingRequestHandler, and the
corrisponding helthcheck file doesn't exist (and expected situation when a
server is out of rotation) Solr is logging a SEVERE error...
{noformat}
SEVERE: org.apache.solr.common.SolrException: Service disabled
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
This is in spite of hte fact that PingRequestHandler explicitly sets the
alreadyLogged boolean to true in the SolrException constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions
[
https://issues.apache.org/jira/browse/SOLR-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-2124:
-
Priority: Minor (was: Major)
SEVERE exceptions are being logged for expected PingRequestHandler
SERVICE_UNAVAILABLE exceptions
-
Key: SOLR-2124
URL: https://issues.apache.org/jira/browse/SOLR-2124
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: James Dyer
Priority: Minor
Fix For: 3.6, 4.0
Attachments: SOLR-2124.patch
As reported by a user, if you use the PingRequestHandler, and the
corrisponding helthcheck file doesn't exist (and expected situation when a
server is out of rotation) Solr is logging a SEVERE error...
{noformat}
SEVERE: org.apache.solr.common.SolrException: Service disabled
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
This is in spite of hte fact that PingRequestHandler explicitly sets the
alreadyLogged boolean to true in the SolrException constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2124) SEVERE exceptions are being logged for expected PingRequestHandler SERVICE_UNAVAILABLE exceptions
[
https://issues.apache.org/jira/browse/SOLR-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232766#comment-13232766
]
Shawn Heisey commented on SOLR-2124:
Thank you, James! I am really looking forward to 3.6.
SEVERE exceptions are being logged for expected PingRequestHandler
SERVICE_UNAVAILABLE exceptions
-
Key: SOLR-2124
URL: https://issues.apache.org/jira/browse/SOLR-2124
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: James Dyer
Priority: Minor
Fix For: 3.6, 4.0
Attachments: SOLR-2124.patch
As reported by a user, if you use the PingRequestHandler, and the
corrisponding helthcheck file doesn't exist (and expected situation when a
server is out of rotation) Solr is logging a SEVERE error...
{noformat}
SEVERE: org.apache.solr.common.SolrException: Service disabled
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:48)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}
This is in spite of hte fact that PingRequestHandler explicitly sets the
alreadyLogged boolean to true in the SolrException constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232770#comment-13232770 ] Robert Muir commented on LUCENE-3885: - Thanks Steven... hmm as a simple workaround can the smokeTester.py (which sits in dev-tools/scripts) just look for ../maven (from its own location as a reference)? smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232771#comment-13232771 ] Steven Rowe commented on LUCENE-3885: - Also, because of the way the POMs are structured, those that aggregate (recurse in sub-modules) but are not parents (e.g. the lucene and solr contrib POMs) are not released, since the release artifacts don't refer to them. Without them, it's impossible to tell which artifacts should be there. smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232774#comment-13232774 ] Steven Rowe commented on LUCENE-3885: - bq. as a simple workaround can the smokeTester.py (which sits in dev-tools/scripts) just look for ../maven (from its own location as a reference)? Yes, I think that should work, but this should be done only if the release branch isn't available, since when there is a release branch, the likelihood of a mismatch between the local checkout and the release branch is higher. smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232778#comment-13232778 ] Steven Rowe commented on LUCENE-3885: - bq. the likelihood of a mismatch between the local checkout and the release branch is higher :) hmm, that's a bit obvious I just meant that relying on the local checkout could be problematic if it's not the same branch as the one over which the RC is being constructed. smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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: [Lucene-java Wiki] Update of ReleaseNote36 by UweSchindler
Uwe, I think what you've added could be misconstrued as Java 7 being a requirement for use of Lucene 3.6.0: Lucene 3.6.0 Release Highlights: + + * Full Java 7 support (requires at least JDK 7u1). Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232780#comment-13232780 ] Robert Muir commented on LUCENE-3885: - ok, that makes sense to me. I agree the checker should try to avoid mismatches... but of course in general using an outdated checker won't really work anyway for tons of possible reasons (i just updated the current one to reflect the new src tree structure). smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232785#comment-13232785 ] Robert Muir commented on LUCENE-3885: - Also long term (not something we should tackle now!) I think it would be ideal if hudson somehow built an actual release and smoketested-itself for our nightly build. This would make things a lot easier and would ensure some things like packaging stay sane on an incremental basis (rather than doing a ton of work at release time). smokeTestRelease.checkMaven should not require a release branch --- Key: LUCENE-3885 URL: https://issues.apache.org/jira/browse/LUCENE-3885 Project: Lucene - Java Issue Type: Bug Components: general/build Reporter: Robert Muir Currently this throws an exception, but I think it should unpack any pom templates it needs from the artifacts themselves. # its nice to be able to generate and test RC's without having an official branch yet. I am currently doing this just to move us closer to release (just trying to find bugs etc). Also anyone should be able to just toss up an RC at any time. # its better to test the artifacts themselves rather than anything in SVN. At the least the -src jars have an svn export so this should work... if it doesn't, then there is a packaging bug. -- 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: [Lucene-java Wiki] Update of ReleaseNote36 by UweSchindler
Ah sorry, will change :-) - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Steven A Rowe [mailto:sar...@syr.edu] Sent: Monday, March 19, 2012 7:03 PM To: dev@lucene.apache.org Subject: RE: [Lucene-java Wiki] Update of ReleaseNote36 by UweSchindler Uwe, I think what you've added could be misconstrued as Java 7 being a requirement for use of Lucene 3.6.0: Lucene 3.6.0 Release Highlights: + + * Full Java 7 support (requires at least JDK 7u1). Steve - 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12811 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12811/ 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=93 closes=92 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=93 closes=92 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) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=93 closes=92 at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) ... 4 more REGRESSION: org.apache.solr.handler.component.QueryElevationComponentTest.testSorting Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testSorting(QueryElevationComponentTest.java:289) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12811 - Failure
Oops, looks related to the QEC stuff I recently committed. Looking into it... -Yonik lucenerevolution.com - Lucene/Solr Open Source Search Conference. Boston May 7-10 On Mon, Mar 19, 2012 at 2:19 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12811/ 8 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=93 closes=92 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=93 closes=92 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) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=93 closes=92 at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) ... 4 more REGRESSION: org.apache.solr.handler.component.QueryElevationComponentTest.testSorting Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testSorting(QueryElevationComponentTest.java:289) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at
start being more official/vocal about Wiki errata pages for release notes?
(some history for those who aren't away) Something we've done on the Solr wiki since day one was have a wiki page dedicated to each of the minor releases (with sub sections for any patch releases) that lists info about the develompent of any releases that haven't happened yet, and important notes about any releases that have (recently we've started including a copy of hte release announcement)... https://wiki.apache.org/solr/Solr3.6 https://wiki.apache.org/solr/Solr3.5 https://wiki.apache.org/solr/Solr3.4 ... https://wiki.apache.org/solr/Solr1.1 These pages initially served as simple info pages about the release, and also as a place for documentation to link to when indicating what version a feature became available. But over time, they've also served as psuedo-errata pages in the rare case where something is overlooked in the release notes of a release, for example... https://wiki.apache.org/solr/Solr1.4 (proposal) I think it would be a good idea to formalize this idea and start promoting these type of pages for both Solr and Core, so that the top of README.txt and CHANGES.txt for all of our future releases contained verbage such as... More information about this release, including any errata related to the release notes, upgrade instructions, or other changes can be found online at... https://wiki.apache.org/lucene-java/Lucene3.6 ...or... https://wiki.apache.org/solr/Solr3.6 ...we can also use these pages during development to collect the release highlights that we intend to include in the rleease notes instead of the existing ReleaseNote36 type pages. Comments / Objections? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: start being more official/vocal about Wiki errata pages for release notes?
On Mon, Mar 19, 2012 at 2:28 PM, Chris Hostetter hossman_luc...@fucit.org wrote: ...we can also use these pages during development to collect the release highlights that we intend to include in the rleease notes instead of the existing ReleaseNote36 type pages. Comments / Objections? What is the purpose beyond release notes? The ReleaseNotes36 type pages have a well-defined purpose, thats the exact release note we will send out. I think they are useful because it prevents the release manager from having to do that work (other people can populate them with a summary of the features). For more detailed stuff, we have CHANGES.txt, what you are suggesting seems like a duplicate of that? -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: start being more official/vocal about Wiki errata pages for release notes?
: What is the purpose beyond release notes? The ReleaseNotes36 type : pages have a well-defined purpose, thats the exact release note we : will send out. : I think they are useful because it prevents the release manager from : having to do that work (other people can populate them with a summary : of the features). : : For more detailed stuff, we have CHANGES.txt, what you are suggesting : seems like a duplicate of that? your only considering the *pre* release use of this page (in which i'm suggestion it can be used *instead* of the ReleaseNotes36 page, not in adition to) *post* release if we discover oh shit, we forgot to include LUCNEE- in the list of CHANGES.txt or damn, we really should have been more explicit about the importance of doing XYZ when upgrading we can add that note to this wiki page -- the URL for which is already listed at the top of the CHANGE.txt as an important place for people to look for errata about the specific release they are using. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3076) Solr should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-3076: --- Attachment: SOLR-3076.patch Committers, Is there plan to commit filtered ToChildBJQ fix from 13/Mar/12 01:04? btw I guess 3.x is also impacted. And about parser itself? Do you like the syntax? What's the plan? Solr should support block joins --- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Attachments: SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- 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] (LUCENENET-465) Error indexing a document end Filed.Store.COMPRESS
[
https://issues.apache.org/jira/browse/LUCENENET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens closed LUCENENET-465.
-
Resolution: Cannot Reproduce
I can't reproduce this problem, and there's been a month and a half of silence
on the issue. If there's still a problem, we can reopen this later.
Error indexing a document end Filed.Store.COMPRESS
--
Key: LUCENENET-465
URL: https://issues.apache.org/jira/browse/LUCENENET-465
Project: Lucene.Net
Issue Type: Bug
Components: .NET API
Affects Versions: Lucene.Net 2.9.4
Environment: Windows 7 x64 Professional, Visual Studio 2010 Ultimate
SP1, .NET 4.0, Lucene.net 2.9.4.1, SharpZipLib 0.86.0.518
Reporter: João Rosa
Priority: Blocker
Labels: lucene
Fix For: Lucene.Net 2.9.4
I'm developing a index, and need to store values compressed, because its
needed to show that info to the user.
I've the current error: Can not load ICSharpCode.SharpZipLib.dll, when I do
the writer.AddDocument(doc);
The DLLs are from NuGet.
Snippet:
//retirar o directório
System.IO.DirectoryInfo directoryInfo = new
System.IO.DirectoryInfo(path);
//criar o directório para o lucene
Directory directory = FSDirectory.Open(directoryInfo);
//instanciar o analyser
Analyzer analyzer = new SnowballAnalyzer(Portuguese);
//abrir o indíce
bool isNew = !IndexReader.IndexExists(directory);
IndexWriter writer = new IndexWriter(directory, analyzer,
isNew, Lucene.Net.Index.IndexWriter.MaxFieldLength.UNLIMITED);
//gravar o documento
Document doc = new Document();
NumericField numericField = new NumericField(id,
Field.Store.YES, false);
numericField.SetIntValue(id);
doc.Add(numericField);
Field field = new Field(title, title, Field.Store.COMPRESS,
Field.Index.ANALYZED);
field.SetBoost(7);
doc.Add(field);
field = new Field(description, tescription,
Field.Store.COMPRESS, Field.Index.ANALYZED);
doc.Add(field);
writer.AddDocument(doc);
writer.Optimize();
//Close the writer
writer.Commit();
writer.Close();
}
catch (Exception ex)
{
throw ex;
}
--
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
Re: start being more official/vocal about Wiki errata pages for release notes?
On Mon, Mar 19, 2012 at 2:37 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : What is the purpose beyond release notes? The ReleaseNotes36 type : pages have a well-defined purpose, thats the exact release note we : will send out. : I think they are useful because it prevents the release manager from : having to do that work (other people can populate them with a summary : of the features). : : For more detailed stuff, we have CHANGES.txt, what you are suggesting : seems like a duplicate of that? your only considering the *pre* release use of this page (in which i'm suggestion it can be used *instead* of the ReleaseNotes36 page, not in adition to) *post* release if we discover oh shit, we forgot to include LUCNEE- in the list of CHANGES.txt or damn, we really should have been more explicit about the importance of doing XYZ when upgrading we can add that note to this wiki page -- the URL for which is already listed at the top of the CHANGE.txt as an important place for people to look for errata about the specific release they are using. I don't understand the difference. If you are saying rename ReleaseNote36 to Release36, then thats fine! But as far as replacing the concept of ReleaseNote36 with some other concept, this is impossible. at some point we are going to send an email with some contents, and if thats gonna be me, I'm not going to type it up myself but have it as a wiki page i copy-paste from... so I don't think it should have other functionality/stuff on it... Does that make sense? -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: start being more official/vocal about Wiki errata pages for release notes?
: I don't understand the difference. If you are saying rename : ReleaseNote36 to Release36, then thats fine! the difference is we explicitly link to the URL of that page in the CHANGES.txt and README.txt with the verbage i suggested... More information about this release, including any errata related to the release notes, upgrade instructions, or other changes can be found online at... https://wiki.apache.org/lucene-java/Lucene3.6 ...or... https://wiki.apache.org/solr/Solr3.6 ...and then if, after publishing the release, we realize we forgot to mention something in the README.txt or CHANGES.txt we update that wiki page to include it there. : at some point we are going to send an email with some contents, and if : thats gonna be me, I'm not going to type it up myself : but have it as a wiki page i copy-paste from... so I don't think it : should have other functionality/stuff on it... : : Does that make sense? not really -- but it's also not really relevant. there wouldn't *be* any other contents on that page when it's time to send the release announcement out, it would only get added after the release (if ever). -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: start being more official/vocal about Wiki errata pages for release notes?
On Mon, Mar 19, 2012 at 3:06 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : I don't understand the difference. If you are saying rename : ReleaseNote36 to Release36, then thats fine! the difference is we explicitly link to the URL of that page in the CHANGES.txt and README.txt with the verbage i suggested... ...and then if, after publishing the release, we realize we forgot to mention something in the README.txt or CHANGES.txt we update that wiki page to include it there. I don't think we should really set ourselves up for failure. Why can't we document the features in the release up-front and put time into trying to make it readable and concise, its going to be put on the website as well as sent via email to a ton of people, and maybe copy-pasted in blogs etc. Making it live won't fix those problems. But see below, I don't really care what happens to these pages after they serve their purpose which is to prevent the RM from having to go thru all the changes and try to figure out what they all mean, which ones are really exciting to end users, and figure out how to concisely word them, organize in some meaningful way, and then put this all inside a nicely formatted email with correct grammar, spelling, dates, release numbers. : at some point we are going to send an email with some contents, and if : thats gonna be me, I'm not going to type it up myself : but have it as a wiki page i copy-paste from... so I don't think it : should have other functionality/stuff on it... : : Does that make sense? not really -- but it's also not really relevant. there wouldn't *be* any other contents on that page when it's time to send the release announcement out, it would only get added after the release (if ever). Its pretty relevant. What i'm saying the point of these pages is so the RM can type in TO: announce@, general@, and press ctrl-A, ctrl-C, ctrl-V, and send. They already have too much to worry about rather than reformatting a wiki page with a different formatting. In other words i think these release notes pages should be the *exact note* along with formatting and everything so that its not all pushed onto the RM. After thats done, personally i dont care what happens to them (they could be improved or whatever) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: start being more official/vocal about Wiki errata pages for release notes?
: I don't think we should really set ourselves up for failure. Why can't : we document the features in the release up-front and put time into : trying to make it readable and concise, its going to be put on the : website as well as sent via email to a ton of people, and maybe : copy-pasted in blogs etc. Making it live won't fix those problems. I'm not saying it will, i'm saying mistakes happen, so let's prepare for the possibility that they happen, and include in the releases a link to an Errata for CHANGES.txt and README.txt : Its pretty relevant. What i'm saying the point of these pages is so : the RM can type in TO: announce@, general@, and press ctrl-A, ctrl-C, Ok, forget the fucking ReleaseNotes pages -- they can stay exactly as they are, the purpose can remain exactly the same, and nothing i'm proposing has to involve them in any way. My suggestion to re-use/rename those pages was simply one of minimizing duplication of content on the wiki as a whole -- i'm sorry for muddling the issue, forget i ever mentioned anything about changing ReleaseNotes36 at all. The crux of my suggestion was, and still is... : Something we've done on the Solr wiki since day one was have a wiki page : dedicated to each of the minor releases .. that lists info about the : develompent of any releases that haven't happened yet, and important : notes about any releases that have (recently we've started including a : copy of hte release announcement)... ... : ... But over time, they've also served as psuedo-errata pages : in the rare case where something is overlooked in the release notes of a : release, for example... : : https://wiki.apache.org/solr/Solr1.4 ... : I think it would be a good idea to formalize this idea and start promoting : these type of pages for both Solr and Core, so that the top of README.txt and : CHANGES.txt for all of our future releases contained verbage such as... : : More information about this release, including any errata related to the : release notes, upgrade instructions, or other changes can be found online : at... : https://wiki.apache.org/lucene-java/Lucene3.6 : ...or... : https://wiki.apache.org/solr/Solr3.6 ...these pages would be entirely for end users, to consult when installing a release, in case there are any Errata information they should be aware of. -Hoss - 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 # 12812 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12812/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testSorting Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testSorting(QueryElevationComponentTest.java:289) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
Re: start being more official/vocal about Wiki errata pages for release notes?
On Mon, Mar 19, 2012 at 3:28 PM, Chris Hostetter hossman_luc...@fucit.org wrote: ...these pages would be entirely for end users, to consult when installing a release, in case there are any Errata information they should be aware of. You can make such an errata page right now (maybe with empty errata) and link it from wherever you want (including the actual release note)? Personally I'm not gonna be upset about it unless its a broken link. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2025 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2025/ 7 tests failed. REGRESSION: org.apache.solr.handler.component.QueryElevationComponentTest.testSorting Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testSorting(QueryElevationComponentTest.java:289) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12813 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12813/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testMarker Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testMarker(QueryElevationComponentTest.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
Re: How to extend TermInfo ?
Thanks for the information. I'd like to store like one float value per item. To implement another query evaluation algo which needs to store information per term. BTW, i might also want to store information per document for each item. It seems currently the payload information are stored in each position the term occurs. Any plans to store add an mechanism to store information per doc? It might be also possible to merge all payload info for one document, but it's a bit computing waste in runtime. On Mon, Mar 19, 2012 at 3:07 AM, Michael McCandless luc...@mikemccandless.com wrote: It is not easy to add new per-term metadata in 3.x. But in trunk (to eventually be 4.0)... you can make your own codec and store additional per-term metadata. What kind of metadata are you wanting to store...? Mike McCandless http://blog.mikemccandless.com On Mon, Mar 19, 2012 at 2:42 AM, lukai lukai1...@gmail.com wrote: Hi, guys: I have needs to add a new data filed in TermInfo. refer to here: http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/fileformats.html#Term Dictionary Do i need to change the term FST build process? Anybody had done this kind of modification before? Thanks, - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: How to extend TermInfo ?
On Mon, Mar 19, 2012 at 5:13 PM, lukai lukai1...@gmail.com wrote: Thanks for the information. You're welcome! I'd like to store like one float value per item. To implement another query evaluation algo which needs to store information per term. OK, sounds neat. BTW, i might also want to store information per document for each item. It seems currently the payload information are stored in each position the term occurs. Any plans to store add an mechanism to store information per doc? In trunk, you can use doc values for this? It might be also possible to merge all payload info for one document, but it's a bit computing waste in runtime. In 3.x, you can make a field for each document, that has only one term occurrence and stores the payload on it? Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232938#comment-13232938 ] Michael McCandless commented on SOLR-3076: -- Hi Mikhail, I've committed fixes for the filtering issues you found in ToChildBJQ, I think...? Are you still seeing issues? I'm unsure of the QP syntax for BJQ... Solr should support block joins --- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Attachments: SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- 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 # 12814 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12814/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testFieldType Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testFieldType(QueryElevationComponentTest.java:76) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2026 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2026/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testTrieFieldType Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testTrieFieldType(QueryElevationComponentTest.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
Cache hit information in log and response header
For debugging applications sometimes it is needed to check if a log entry was found in the query results cache or not. Currently that information is not available and one can only speculate based on the query time. As another idea, this can also be done with the filter cache and show an array of booleans to show which filters hit and which didn't. The changes to the SolrIndexSearcher and QueryComponent are minimal and I already added them to make some tests. What are your opinions on creating a ticket for this in Jira? Thanks Emmanuel - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: How to extend TermInfo ?
Thx, i will try to move to 4.x version. On Mon, Mar 19, 2012 at 2:24 PM, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 19, 2012 at 5:13 PM, lukai lukai1...@gmail.com wrote: Thanks for the information. You're welcome! I'd like to store like one float value per item. To implement another query evaluation algo which needs to store information per term. OK, sounds neat. BTW, i might also want to store information per document for each item. It seems currently the payload information are stored in each position the term occurs. Any plans to store add an mechanism to store information per doc? In trunk, you can use doc values for this? It might be also possible to merge all payload info for one document, but it's a bit computing waste in runtime. In 3.x, you can make a field for each document, that has only one term occurrence and stores the payload on it? Smart solution... :) Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2026 - Still Failing
I can no longer reproduce this locally... I think the build directories just need to be cleaned out? I don't have a login to the build server though (or I forgot it). -Yonik lucenerevolution.com - Lucene/Solr Open Source Search Conference. Boston May 7-10 On Mon, Mar 19, 2012 at 5:56 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2026/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testTrieFieldType Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testTrieFieldType(QueryElevationComponentTest.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at
[jira] [Created] (SOLR-3256) Distributed search throws NPE when using fl=score
Distributed search throws NPE when using fl=score - Key: SOLR-3256 URL: https://issues.apache.org/jira/browse/SOLR-3256 Project: Solr Issue Type: Bug Reporter: Tomás Fernández Löbbe Priority: Minor Fix For: 4.0 Steps to reproduce the problem: Start two Solr instances (may use the example configuration) add some documents to both instances execute a query like: http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:8984/solrq=(ipod%20OR%20display)*fl=score* Expected result: List of scores or at least an exception saying that this request is not supported (may not make too much sense to do fl=score, but a descriptive exception can help debug the problem) Getting: SEVERE: null:java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:985) at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:637) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:612) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:636) -- 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 # 12815 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12815/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testElevationReloading Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(QueryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testElevationReloading(QueryElevationComponentTest.java:433) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618) 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:20) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at 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.solr.common.SolrException at org.apache.solr.core.SolrCore.init(SolrCore.java:614) at org.apache.solr.core.SolrCore.init(SolrCore.java:498) at
RE: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2026 - Still Failing
Hi, I wiped the workspace. But in general, the build script ant cleans the build, so it should be correctly cleaned up? Is there a bug in the cleanup? The Jenkins password is taken from LDAP: login on Jenkins web interface with apache id, and click on wipe workspace. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik Seeley Sent: Monday, March 19, 2012 11:31 PM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2026 - Still Failing I can no longer reproduce this locally... I think the build directories just need to be cleaned out? I don't have a login to the build server though (or I forgot it). -Yonik lucenerevolution.com - Lucene/Solr Open Source Search Conference. Boston May 7-10 On Mon, Mar 19, 2012 at 5:56 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2026/ 7 tests failed. FAILED: org.apache.solr.handler.component.QueryElevationComponentTest.testTrie FieldType Error Message: org.apache.solr.common.SolrException Stack Trace: java.lang.RuntimeException: org.apache.solr.common.SolrException at org.apache.solr.util.TestHarness.init(TestHarness.java:152) at org.apache.solr.util.TestHarness.init(TestHarness.java:135) at org.apache.solr.util.TestHarness.init(TestHarness.java:125) at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:342) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:335) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:158) at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:147) at org.apache.solr.handler.component.QueryElevationComponentTest.init(Que ryElevationComponentTest.java:64) at org.apache.solr.handler.component.QueryElevationComponentTest.init(Que ryElevationComponentTest.java:52) at org.apache.solr.handler.component.QueryElevationComponentTest.testTrie FieldType(QueryElevationComponentTest.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j ava:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess orImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkM ethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCall able.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMet hod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMeth od.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.j ava:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.jav a:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPr opertiesRestoreRule.java:20) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.eval uate(LuceneTestCase.java:729) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.eval uate(LuceneTestCase.java:645) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(System PropertiesInvariantRule.java:22) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.eval uate(LuceneTestCase.java:556) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExcep tionsRule.java:51) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(Lu ceneTestCase.java:618) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunn er.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRun ner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRun ner.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.j ava:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.jav a:30)
[jira] [Assigned] (LUCENE-3886) MemoryIndex memory estimation in toString inconsistent with getMemorySize()
[ https://issues.apache.org/jira/browse/LUCENE-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-3886: - Assignee: Uwe Schindler MemoryIndex memory estimation in toString inconsistent with getMemorySize() --- Key: LUCENE-3886 URL: https://issues.apache.org/jira/browse/LUCENE-3886 Project: Lucene - Java Issue Type: Bug Components: modules/other Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.6, 4.0 After LUCENE-3867 was committed, there are some more minor problems with MemoryIndex's estimates. This patch will fix those and also add verbose test output of RAM needed for MemoryIndex vs. RAMDirectory. Interestingly, the RAMDirectory always takes (according to estimates, so even with buffer overheads) only 2/3 of the MemoryIndex (excluding IndexReaders). -- 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-3886) MemoryIndex memory estimation in toString inconsistent with getMemorySize()
MemoryIndex memory estimation in toString inconsistent with getMemorySize() --- Key: LUCENE-3886 URL: https://issues.apache.org/jira/browse/LUCENE-3886 Project: Lucene - Java Issue Type: Bug Reporter: Uwe Schindler After LUCENE-3867 was committed, there are some more minor problems with MemoryIndex's estimates. This patch will fix those and also add verbose test output of RAM needed for MemoryIndex vs. RAMDirectory. Interestingly, the RAMDirectory always takes (according to estimates, so even with buffer overheads) only 2/3 of the MemoryIndex (excluding IndexReaders). -- 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-3886) MemoryIndex memory estimation in toString inconsistent with getMemorySize()
[ https://issues.apache.org/jira/browse/LUCENE-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3886: -- Component/s: modules/other Fix Version/s: 4.0 3.6 MemoryIndex memory estimation in toString inconsistent with getMemorySize() --- Key: LUCENE-3886 URL: https://issues.apache.org/jira/browse/LUCENE-3886 Project: Lucene - Java Issue Type: Bug Components: modules/other Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.6, 4.0 After LUCENE-3867 was committed, there are some more minor problems with MemoryIndex's estimates. This patch will fix those and also add verbose test output of RAM needed for MemoryIndex vs. RAMDirectory. Interestingly, the RAMDirectory always takes (according to estimates, so even with buffer overheads) only 2/3 of the MemoryIndex (excluding IndexReaders). -- 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-3886) MemoryIndex memory estimation in toString inconsistent with getMemorySize()
[ https://issues.apache.org/jira/browse/LUCENE-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3886: -- Attachment: LUCENE-3886.patch Simple patch with cleanup. Will commit this soon to get 3.6 running. MemoryIndex memory estimation in toString inconsistent with getMemorySize() --- Key: LUCENE-3886 URL: https://issues.apache.org/jira/browse/LUCENE-3886 Project: Lucene - Java Issue Type: Bug Components: modules/other Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.6, 4.0 Attachments: LUCENE-3886.patch After LUCENE-3867 was committed, there are some more minor problems with MemoryIndex's estimates. This patch will fix those and also add verbose test output of RAM needed for MemoryIndex vs. RAMDirectory. Interestingly, the RAMDirectory always takes (according to estimates, so even with buffer overheads) only 2/3 of the MemoryIndex (excluding IndexReaders). -- 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-3887) 'ant javadocs' should fail if a package is missing a package.html
'ant javadocs' should fail if a package is missing a package.html - Key: LUCENE-3887 URL: https://issues.apache.org/jira/browse/LUCENE-3887 Project: Lucene - Java Issue Type: Task Components: general/build Reporter: Robert Muir While reviewing the javadocs I noticed many packages are missing a basic package.html. For 3.x I committed some package.html files where they were missing (I will port forward to trunk). I think all packages should have this... really all public/protected classes/methods/constants, but this would be a good step. -- 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-3886) MemoryIndex memory estimation in toString inconsistent with getMemorySize()
[ https://issues.apache.org/jira/browse/LUCENE-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3886. --- Resolution: Fixed Committed trunk revision: 1302709 Committed 3.x revision: 1302717 MemoryIndex memory estimation in toString inconsistent with getMemorySize() --- Key: LUCENE-3886 URL: https://issues.apache.org/jira/browse/LUCENE-3886 Project: Lucene - Java Issue Type: Bug Components: modules/other Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.6, 4.0 Attachments: LUCENE-3886.patch After LUCENE-3867 was committed, there are some more minor problems with MemoryIndex's estimates. This patch will fix those and also add verbose test output of RAM needed for MemoryIndex vs. RAMDirectory. Interestingly, the RAMDirectory always takes (according to estimates, so even with buffer overheads) only 2/3 of the MemoryIndex (excluding IndexReaders). -- 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-3885) smokeTestRelease.checkMaven should not require a release branch
[
https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-3885:
Attachment: LUCENE-3885.patch
Fixes {{smokeTestRelease.py}} to refer to the local working copy if the RC URL
supplied on the cmdline does not name a release branch.
Also, I commented out the check that Maven artifacts are exactly identical to
their counterparts in the binary distribution.
Committing shortly.
smokeTestRelease.checkMaven should not require a release branch
---
Key: LUCENE-3885
URL: https://issues.apache.org/jira/browse/LUCENE-3885
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Reporter: Robert Muir
Attachments: LUCENE-3885.patch
Currently this throws an exception, but I think it should unpack any pom
templates it needs from the artifacts themselves.
# its nice to be able to generate and test RC's without having an official
branch yet. I am currently doing this just to
move us closer to release (just trying to find bugs etc). Also anyone
should be able to just toss up an RC at any time.
# its better to test the artifacts themselves rather than anything in SVN. At
the least the -src jars have an svn export
so this should work... if it doesn't, then there is a packaging bug.
--
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
